Hi Mike, thanks for your quick response.
On 06/05/2014 07:46 PM, Mike Jones 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. Regarding the different structure between the access token and the ID token: As I tried to explain with my example they two may carry almost the same information (if the access token carries the information per value and uses the JWT encoding). Regarding the opaque nature: I think it is important to also add for whom the tokens are opaque. From the text in the document the access token and the ID token seem to be opaque for the client but they are not opaque for the party generating them (=authorization server) and also not opaque for the party consuming them (=resource server). > > 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. The problems with the security breaches had nothing to do with the encoding of the information in the token itself, which is what I am referring to. Ciao Hannes > > -- 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 >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
