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

Phil Hunt phil.hunt at oracle.com
Tue Oct 3 16:35:32 UTC 2017


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> 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
> 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/d0dcc256/attachment.html>


More information about the Openid-specs-ab mailing list