Re: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call

[Hans Zandbelt <[e-mail]>]

a deployment-related question that I have around this topic:

it seems that authentication using OAuth 2.0 is possible today for 
confidential clients using the code flow, with a registered 
redirect_uri, not consuming/storing/using refresh_tokens, and assuming 
that there's an API that returns user identity info in JSON format and 
the claim that uniquely identifies the user is known by the client.

The usage/presence of the short-lived code in this scenario/flow 
guarantees that the user has just authenticated, and the audience issue 
is covered by the fact that the code (thus the access_token in the token 
endpoint response) are bound to the confidential client, all as per 
standard OAuth 2.0 semantics.

2 questions about that:
- is this right or am I overlooking some security/semantics issues here
- if right, would it make sense to acknowledge that or is that muddying 
the waters even more (the current text does seem to only implicitly 
acknowledge this)

There may be value in acknowledging this because the majority of OAuth 
2.0 OPs exposing a userinfo-like API would adhere to a REST GET+JSON 
response anyhow [1] thus achieving login semantics with plain OAuth 2.0 
and a bit of common practice wrt. the user info API.

Thanks for the excellent write-up!

Hans.

PS: I've been asked this concrete question about Spotify's OAuth 2.0 
support and in fact I'm able to configure Spotify as an IDP to my OIDC 
client with a minor workaround to abstain from expecting an id_token in 
the token endpoint response, but calling the Spotify specific user info 
endpoint like it was a standards-compliant OpenID Connect endpoint. (the 
client has a per-OP configurable unique user id claim name anyhow).

On 10/16/14, 7:27 PM, Richer, Justin P. wrote:
> Ah yes, good catch! If only someone would put up a webpage describing the difference between authorization and authentication and why people need to stop confusing the two.
>
> Oh wait...
>
>
> On Oct 16, 2014, at 1:06 PM, Hans Zandbelt <[e-mail]> wrote:
>
>> About the write-up: at the end of the metaphor section it says:
>> "These recipes each add a number of items, such as a common profile API, to OAuth to create an authorization protocol."
>>
>> whereas I believe that should read "to create an authentication protocol"
>>
>> Hans.
>>
>> On 10/16/14, 6:54 PM, Hannes Tschofenig wrote:
>>> Participants:
>>>
>>>   * Brian Campbell
>>>   * John Bradley
>>>   * Derek Atkins
>>>   * Phil Hunt
>>>   * William Kim
>>>   * Josh Mandel
>>>   * Hannes Tschofenig
>>>
>>>
>>> Notes:
>>>
>>> Justin distributed a draft writeup and explained the reasoning behind
>>> it. The intended purpose is to put the write-up (after enough review) on
>>> oauth.net. See attachments. Justin solicited feedback from the
>>> conference call participants and from the working group.
>>>
>>> One discussion item was specifically related to the concept of audience
>>> restrictions, which comes in two flavours: (a) restriction of the access
>>> token regarding the resource server and (b) restriction of the id token
>>> regarding the client. Obviously, it is necessary to have both of these
>>> audience restrictions in place and to actually check them.
>>>
>>> The group then went into a discussion about the use of pseudonyms in
>>> authentication and the problems deployments ran into when they used
>>> pseudonyms together with a wide range of attributes that identified
>>> users nevertheless. Phil suggested to produce a write-up about this topic.
>>>
>>> Finally, the group started a discussion about potential actions for the
>>> OAuth working groups. Two activities were mentioned, namely to produce
>>> an IETF draft of the write-up Justin has prepared as a "formal" response
>>> to the problems with authentication using OAuth and, as a second topic,
>>> potential re-chartering of the OAuth working group to work on some
>>> solutions in this area. Hannes suggested to postpone these discussions
>>> and to first finish the write-up Justin had distributed.
>>>
>>> Ciao
>>> Hannes & Derek
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>> --
>> Hans Zandbelt              | Sr. Technical Architect
>> [e-mail] | Ping Identity
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
Hans Zandbelt              | Sr. Technical Architect
[e-mail] | Ping Identity