Month: May 2014

Open ID Connect 1.0 with oAuth 2.0 is for managing authentication, authorization and single sign on for service oriented or distributed enterprise applications.

Posted on Updated on

Every service oriented or distrusted enterprise applications needs authentication, authorization and single sign on (SSO) to manage the users. In era of Service Oriented Architecture the same need is fulfilled by WS-Federation, WS-Trust and SAML  along with WS-* specification. In some cases custom framework is designed to do it and still they can continue with it, there is no harm in doing so as well. But thing has been changed in last few years because of wide adoption of internet, smart phones and social networking sites like Facebook, Google Plus etc…

Problem Definition: The need or demand of time is to allow the users from Social Networking sites to get register with the enterprise application in most of cases user’s already have account in some of the social networking site and applications pull the existing user profile. Need to support the common protocol to manage the user’s authentication, authorization and SSO from different types of applications like server side web applications, native mobile applications, browser based client side applications or desk top applications with respect any technology. Need to protect the access of web services which are publically exposed.

Solution:   This solution is referring terms from oAuth 2.0 and Open Id Connect 1.0 specification. If you are not aware about it please go through it once.

To begin with the scenario let me introduce the player/actors involve in it using following picture:

sso

 

Here we have relying party as a web application which is in interest of user. The relying party providing some set of services to users like gmail, wordpress or any web application. The relying party is depends on another web application for authentication which is known as identity provider (IDP). The responsibility of IDP is to authenticate the user using underline authentication provider like database, active directory or any other source of authentication provider like Facebook. Once user is authenticated from IDP user is redirected to relying party. User access this web application using a User agent (web browser). In this scenario we have user as resource owner, web browser or user agent, relying party and identity provider.

Now we can explore Open Id connect 1.0 basic client flow. In this case the Identity Server acting as open Id connect 1.0 and oAuth 2.0 provider aka identity provider (IDP). Relying party is the web application which is open id connect 1.0 or oAuth 2.0 clients. The Relying party can access services endpoints like google api or facebook graph api which are secured by oAuth 2.0 access token aka Resource Server. The authentication and authorization between relying party, IDP and resource server code flow is mentioned as below.

oidc flow

Single Sign On

The single sign in is achieved based on browser http only secured session cookie. Once Relying party user is authenticated by IDP a secure http session cookie is added in response. If some other relying party the user trying to access from same identity provider he can initiate the IDP authenticated session from the previous secure session cookie.

The single sign out for relying parties is achieved based on session management profile of open id connect 1.0 specification.  In this case two more endpoints are exposed by IDP as Open ID Provider as check session iframe endpoint for checking valid session and end session end point for log out initiation from relying parties.

 

References:

http://openid.net/specs/openid-connect-session-1_0.html

http://tools.ietf.org/html/rfc6749

http://openid.net/connect/

http://vimeo.com/70556512

https://www.youtube.com/watch?v=hEewiXlynyc

Thinktecture.IdentityServer.v3

MITREid Connect

Advertisements