[Openid-specs-ab] JWT Access Token <> ID Token mixups

[George Fletcher]

I don't think so because it's a hint. If that user doesn't want to sign 
in, they can often switch to a different user.

On 10/3/17 12:35 PM, Phil Hunt wrote:
> Isn’t there an audience issue here?
>
> Phil
>
> Oracle Corporation, Identity Cloud Services Architect
> @independentid
> www.independentid.com <http://www.independentid.com>
> phil.hunt at oracle.com <mailto:phil.hunt at oracle.com>
>
>> On Oct 2, 2017, at 8:10 AM, George Fletcher via Openid-specs-ab 
>> <openid-specs-ab at lists.openid.net 
>> <mailto:openid-specs-ab at lists.openid.net>> wrote:
>>
>> If the JWT was issued by the same OP/AS it's being presented to as an 
>> id_token_hint, and the OP can securely determine the user from the 
>> access token then I don't think there are any security issues in this 
>> flow. The biggest issue might be that the valid access token is now 
>> flowing through the browser and hence is subject to a 
>> man-in-the-browser capture and replay attack.
>>
>> Thanks,
>> George
>>
>> On 10/2/17 10:31 AM, Filip Skokan wrote:
>>> Original question was purely concerned about the OPs accepting a JWT 
>>> formatted access tokens in places where ID Token is expected, e.g. 
>>> id_token_hint for authorization or logout request.
>>>
>>> Is that something to be concerned about?
>>>
>>> Best,
>>> *Filip Skokan*
>>>
>>> On Mon, Oct 2, 2017 at 4:28 PM, George Fletcher <gffletch at aol.com 
>>> <mailto:gffletch at aol.com>> wrote:
>>>
>>>     In the cases you've run across... do they really use the
>>>     id_token as an access_token? or rather as a bootstrap token into
>>>     new refresh/access tokens? Given that in most cases id_tokens do
>>>     not contain scopes it seems weird to use them as access tokens
>>>     (the different between authentication and authorization).
>>>
>>>     Thanks,
>>>     George
>>>
>>>
>>>     On 10/2/17 3:02 AM, Dominick Baier via Openid-specs-ab wrote:
>>>>     We’ve come across a number of implementations that promote the
>>>>     use of id_tokens as access tokens e.g. Microsoft Azure AD
>>>>     (B2C), Google and Auth0.
>>>>
>>>>     Every time we argue with e.g. Microsoft - they say “we did our
>>>>     own threat modelling and its fine”. So maybe the spec should be
>>>>     very explicit about why this is not allowed or when exactly
>>>>     this is OK or not.
>>>>
>>>>     There is a long thread here:
>>>>     https://github.com/IdentityServer/IdentityServer3/issues/2015
>>>>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_IdentityServer_IdentityServer3_issues_2015&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=mdDV8XhVQVLAfkuK-l3w8eRNsa67if9SJfSkAbg0sbc&s=V9Wy-oAo8x7-kicEYAtUPei6HGA6mPbfnp1j3iLfNrA&e=>
>>>>
>>>>
>>>>     -------
>>>>     Dominick Baier
>>>>
>>>>     On 29. September 2017 at 07:56:56, Filip Skokan via
>>>>     Openid-specs-ab (openid-specs-ab at lists.openid.net
>>>>     <mailto:openid-specs-ab at lists.openid.net>) wrote:
>>>>
>>>>>     Hello everyone,
>>>>>
>>>>>     I'm certain you've came across authorization servers issuing
>>>>>     JWT-formatted Access Tokens by now. Most frequently these are
>>>>>     following the JWT profile just like an ID Token does, opening
>>>>>     up the possibility an Access Token is a perfect ID Token
>>>>>     lookalike and can be used i.e. as id_token_hint.
>>>>>
>>>>>       * Is this a valid concern?
>>>>>       * Shouldn't the JWT "typ" header parameter be used to strong
>>>>>         type the ID Token (similar to SETs secevent+jwt)?
>>>>>       * Any other way ID Tokens could have a unique required
>>>>>         claims making it possible to differentiate between JWT
>>>>>         Access Tokens and ID Tokens?
>>>>>
>>>>>     If not part of the specs, should the OPs supporting JWT access
>>>>>     tokens be at least recommended to push unique claims to their
>>>>>     JWTs to be able to distinguish between the different JWT uses?
>>>>>
>>>>>     Penny for your thoughts.
>>>>>
>>>>>     Best Regards,
>>>>>     *Filip Skokan*
>>>>>     _______________________________________________
>>>>>     Openid-specs-ab mailing list
>>>>>     Openid-specs-ab at lists.openid.net
>>>>>     <mailto:Openid-specs-ab at lists.openid.net>
>>>>>     http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>     <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dab&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=mdDV8XhVQVLAfkuK-l3w8eRNsa67if9SJfSkAbg0sbc&s=RVKEhccvJuz61dc-swlMFWP7QMKR5NpjgXqoEvTEyFc&e=>
>>>>>
>>>>
>>>>
>>>>     _______________________________________________
>>>>     Openid-specs-ab mailing list
>>>>     Openid-specs-ab at lists.openid.net
>>>>     <mailto:Openid-specs-ab at lists.openid.net>
>>>>     http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>     <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dab&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=mdDV8XhVQVLAfkuK-l3w8eRNsa67if9SJfSkAbg0sbc&s=RVKEhccvJuz61dc-swlMFWP7QMKR5NpjgXqoEvTEyFc&e=>
>>>
>>>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net 
>> <mailto:Openid-specs-ab at lists.openid.net>
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dab&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=mdDV8XhVQVLAfkuK-l3w8eRNsa67if9SJfSkAbg0sbc&s=RVKEhccvJuz61dc-swlMFWP7QMKR5NpjgXqoEvTEyFc&e= 
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20171003/4860da39/attachment.html>