
By Francois Lascelles | Article Rating: |
|
June 21, 2012 07:00 PM EDT | Reads: |
1,782 |

The idea of delegating the authentication of a user to a 3rd party is ancient. At some point however, a clever (or maybe lazy) developer thought to leverage an OAuth handshake to achieve this. In the first part of this blog post, I pointed out winning patterns associated with the popular social login trend. In this second part, I suggest the use of specific standards to achieve the same for your identities.
OAuth was originally conceived as a protocol allowing an application to consume an API on behalf of a user. As part of an OAuth handshake, the API provider authenticates the user. The outcome of the handshake is the application getting an access token. This access token does not directly provide useful information for the application to identify the user. However, when that provider exposes an API which returns information about that user, the application can use this as a means to close the loop on the delegated authentication.
Step 1 – User is subjected to an OAuth handshake with provider knowing its identity.
Step 2 – Application uses the access token to discover information about the user by calling an API.
As a provider enabling an application to discover the identity of a user through such a sequence, you could define your own simple API. Luckily, an emerging standard covers such semantics: OpenID Connect. Currently a draft spec, OpenID Connect defines (among other things) a “user info” endpoint which takes as input an OAuth access token and returns a simple JSON structure containing attributes about the user authenticated as part of the OAuth handshake.
Request:
GET /userinfo?schema=openid HTTP/1.1
Host: server.example.com
Authorization: Bearer SlAV32hkKG
Response:
200 OK
content-type: application/json
{
“user_id”: “248289761001″,
“name”: “Jane Doe”,
“given_name”: “Jane”,
“family_name”: “Doe”,
“email”: “[email protected]”,
“picture”: “http://example.com/janedoe.jpg”
}
In the Layer 7 Gateway OpenID Connect, a generic user info endpoint is provided which validates an incoming OAuth access token and returns user attributes for the user associated with said token. You can plug in your own identity attributes as part of this user info endpoint implementation. For example, if you are managing identities using an LDAP provider, you inject an LDAP query in the policy as illustrated below.
To get the right LDAP record, the query is configured to take as input the variable ${session.subscriber_id}. This variable is automatically set by the OAuth toolkit as part of the OAuth access token validation. You could easily lookup the appropriate identity attributes from a different source using for example a SQL query or even an API call – all the input necessary to discover these attributes is available to the manager.
Another aspect of OpenID Connect is the issuing of id tokens during the OAuth handshake. This id token is structured following the JSON Web Token specification (JWT) including JWS signatures. Layer 7’s OpenID Connect introduces the following assertions to issue and handle JWT-based id tokens:
- Generate ID Token
- Decode ID Token
Note that as of this writing, OpenID Connect is a moving target and the specification is subject to change before finalization.

Read the original blog entry...
Published June 21, 2012 Reads 1,782
Copyright © 2012 SYS-CON Media, Inc. — All Rights Reserved.
Syndicated stories and blog feeds, all rights reserved by the author.
More Stories By Francois Lascelles
As Layer 7’s Chief Architect, Francois Lascelles guides the solutions architecture team and aligns product evolution with field trends. Francois joined Layer 7 in the company’s infancy – contributing as the first developer and designing the foundation of Layer 7’s Gateway technology. Now in a field-facing role, Francois helps enterprise architects apply the latest standards and patterns. Francois is a regular blogger and speaker and is also co-author of Service-Oriented Infrastructure: On-Premise and in the Cloud, published by Prentice Hall. Francois holds a Bachelor of Engineering degree from Ecole Polytechnique de Montreal and a black belt in OAuth. Follow Francois on Twitter: @flascelles
![]() Apr. 26, 2018 01:15 AM EDT Reads: 5,080 |
By Elizabeth White ![]() Apr. 26, 2018 01:00 AM EDT Reads: 7,656 |
By Elizabeth White ![]() Apr. 26, 2018 12:45 AM EDT Reads: 4,780 |
By Elizabeth White ![]() Apr. 26, 2018 12:15 AM EDT Reads: 11,218 |
By Pat Romanski ![]() Apr. 25, 2018 11:45 PM EDT Reads: 2,044 |
By Elizabeth White Apr. 25, 2018 11:45 PM EDT Reads: 6,948 |
By Elizabeth White ![]() Apr. 25, 2018 11:00 PM EDT Reads: 6,532 |
By Yeshim Deniz Apr. 25, 2018 11:00 PM EDT Reads: 2,739 |
By Liz McMillan ![]() Apr. 25, 2018 11:00 PM EDT Reads: 3,742 |
By Yeshim Deniz ![]() Apr. 25, 2018 10:00 PM EDT Reads: 6,952 |
By Pat Romanski ![]() Apr. 25, 2018 09:15 PM EDT Reads: 4,238 |
By Liz McMillan ![]() Apr. 25, 2018 09:15 PM EDT Reads: 17,595 |
By Elizabeth White ![]() Apr. 25, 2018 09:15 PM EDT Reads: 9,313 |
By Liz McMillan ![]() Apr. 25, 2018 09:15 PM EDT Reads: 22,835 |
By Elizabeth White ![]() Apr. 25, 2018 09:15 PM EDT Reads: 4,655 |