+1 to Hannes comments.
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
_______________________________________________
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
