[Openid-specs-ab] Other grant types and scope openid

Nat Sakimura sakimura at gmail.com
Mon Jul 30 06:55:59 UTC 2012

ID Token is not tied to the browser session, but it is tided to the
authentication session wherever it happened.
It could be app that is in the session, and it could be a browser.
The important thing is that it is tied to the user being present in
the session.

If you do not use ID Token, it is not an authentication session anymore.
ID Token always returns the information about the user who
authenticated (and authorized resource access.)
The result of resource access (e.g., profile data) does not have to be
that of the person who authorized.
For example, the university controller may allow access to the
graduation record of the subject to the company
the subject has applied to. While the profile data returns that of the
subject, the ID Token returns the
information about the controller.

So, as long as you want to do Authentication, you should always use ID Token.
Otherwise, you need to create a proprietary API that essentially act
the same as ID Token.
OAuth 2.0 as is does not provide that facility.


On Mon, Jul 30, 2012 at 3:17 PM, Torsten Lodderstedt
<torsten at lodderstedt.net> wrote:
> Hi all,
> what is the expected behavior in case a client requests the scope "openid"
> with a grant type other than code or token? For example, an app could
> request it at the token endpoint using "Resource Owner Password
> Credentials". Given the recent discussion on refresh tokens and id tokens,
> the id token concept seems to be tight to browser sessions. So I don't see a
> need to return an id token to apps in cases where no browser session is
> involved.
> Comments?
> regards,
> Torsten.
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

Nat Sakimura (=nat)
Chairman, OpenID Foundation

More information about the Openid-specs-ab mailing list