[Openid-specs-ab] Check ID Immediate

John Bradley ve7jtb at ve7jtb.com
Mon Oct 3 21:25:50 UTC 2011


The RP may want to silently login a returning user if they know the users IdP, or they may want to confirm that the user they have currently logged in still has an active session with their OP.
This is typically done through a iframe giving the OP no place to percent a dialog.

In openID 2.0 this was called check_id_imediate.

In OAuth 2.0 we can specify a response_type of id_token if we don't require an access token.
Using the OAuth display parameter in the existing spec the OP can be signalled not to present the user with any dialog.

The request would be:
https://server.example.com/op/authorize?
response_type=id_token
&display=none
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
&scope=openid
&state=af0ifjsldkj

The response would be fragment encoded if positive.

The likely error codes are (From messages 3.1.4.1):
login_required:  User has no session
session_selection_required:  Multiple sessions at OP
approval_required:  User has not authorized the RP to log them in.

Some IdP may choose to  return login_required vs approval_required to prevent unknown RP from determining if the user has an account.

In the case where the user has multiple sessions at the IdP being able to send a hint from the RP would be beneficial.  In the case where you just want to check if the session for a particular user is still active.
The simpler way to do that would be to send the id_token in the request.

I think this is a better approach than having the special session management endpoint.
The "code", "token id_token" and "code id_token" flows work as well.  You would use those if the user doesn't already have a access token, and you need one.

We do currently have the id_tokens expiring.  Should a RP with an expired id_token perform the display-none flow to get a fresh id_token?
I suspect that IdP will set the lifetime on id_tokens to be long.  Especially if they are supporting a active SLO mechanism.

I don't think this requires any normative changes to the existing spec, unless we want to add the ability to send the id_token in the authorization request.

I do think we need to add a section explaining the display=none behaviour.

John B.




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20111003/22902791/attachment.p7s>


More information about the Openid-specs-ab mailing list