+1 the access token is opaque to the client. That's great! Let's keep it that way.
> Am 05.06.2014 um 21:20 schrieb Bill Mills <wmills_92...@yahoo.com>: > > Can't agree more with the peril of overloading auth information into an > access token. > > > On Thursday, June 5, 2014 11:05 AM, Mike Jones <michael.jo...@microsoft.com> > wrote: > > > Hannes, the Access Token and ID Token do quite different things and have > different structures and properties. The Access Token is an opaque value > that grants access to resources. An ID Token is a non-opaque JWT security > token that makes claims about the authentication that occurred. You can have > one without the other or you can have both, depending upon the use case. > Thus, trying to move information between them would be problematic in several > regards. > > Also, trying to overload the Access Token to convey authentication > information has been demonstrated in practice to be fraught with peril, and > has resulted in some of the most prominent security breaches related to the > misuse of OAuth. > > -- Mike > > -----Original Message----- > From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt > Sent: Thursday, June 05, 2014 8:54 AM > To: Hannes Tschofenig > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c > > You are correct. Just adding to access token would make a lot of devs happy > and that certainly should be discussed. > > Two requirements issues: > > 1. A key use case is passing auth ctx only. An access token means asking for > consent to access something. This causes many sites to loose new users. > Authen only can be implicit consent. > > 2. Compatibility with OpenId ID Token and flows. > > 3. There is a need to support re-auth and MFA/LOA negotiation. Eg web site > would like to obtain a higher level of assurance for a higher risk action. > > The non-tech requirement is the soln must be received by client and service > provider developers as easy to implement in addition to 6749 or even OAuth > 1.1a. I mention it because devs feel this should be trivial. Your suggestion > of adding to access token certainly fits this. > > Phil > > > On Jun 5, 2014, at 0:44, Hannes Tschofenig <hannes.tschofe...@gmx.net> > > wrote: > > > > Hi Phil, > > > > thanks for producing this document write-up. I have a somewhat basic > > question regarding the document. > > > > The id token contains the following mandatory information: > > - sis: issuer > > - sub: subject > > - aud: audience > > - iat: issued at > > - exp: expiry > > - auth_time: time when the end user was authenticated > > > > An access token (when encoded as a JWT) may contain all these fields > > except the auth_time (since auth_time is not defined in the JWT spec). > > > > Given that your proposal actually does not define the authentication > > protocol to be used between the resource owner/end user and the > > authorisation server I am wondering whether it would be possible to > > just add the auth_time parameter (and maybe some of the optional > > parameters) to the access token. Then, you can skip the id token. > > > > How do I come up with that question? In Kerberos, for example, the > > above-listed information is carried within a single container (within > > the ticket) and so I am curious to hear why we have to send the > > information twice in OAuth (once in the access token, when the info is > > passed per value, and again via the id token). > > > > Maybe I missing something important here. > > > > Ciao > > Hannes > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
