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

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 16 Oct 2014 18:54:40 +0200

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

---

From: Hans Zandbelt <[email-masked]>
Date: Thu, 16 Oct 2014 19:06:27 +0200

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:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
Hans Zandbelt              | Sr. Technical Architect
[email-masked] | Ping Identity

---

From: Mike Jones <[email-masked]>
Date: Thu, 16 Oct 2014 17:17:20 +0000

For what it's worth, I was on the call too - until I and Brian left to join the telechat for the OAuth assertions drafts.

				-- Mike

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Thursday, October 16, 2014 9:55 AM
To: [email-masked]
Subject: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call

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

---

From: "Richer, Justin P." <[email-masked]>
Date: Thu, 16 Oct 2014 17:27:02 +0000

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 <[email-masked]> wrote:

> "These recipes each add a number of items, such as a common profile API, to OAuth to create an authorization protocol."
>

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 16 Oct 2014 17:30:34 +0000

Same here

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Thursday, October 16, 2014 10:17 AM
To: Hannes Tschofenig; [email-masked]
Subject: Re: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call

				-- Mike

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Thursday, October 16, 2014 9:55 AM
To: [email-masked]
Subject: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call

Participants:

 * Brian Campbell
 * John Bradley
 * Derek Atkins
 * Phil Hunt
 * William Kim
 * Josh Mandel
 * Hannes Tschofenig

Notes:

Ciao
Hannes & Derek

---

From: "Richer, Justin P." <[email-masked]>
Date: Thu, 16 Oct 2014 19:58:49 +0000

Those interested in helping edit the text directly can follow along on this GitHub fork:

https://github.com/jricher/oauth.net/tree/authentication

Once a reasonable number of eyes have seen that page, we'll get it published onto oauth.net. Aaron Parecki has offered to add a "Draft" banner to the article page, inviting comments and edits via GitHub.

 -- Justin

On Oct 16, 2014, at 12:54 PM, Hannes Tschofenig <[email-masked]> wrote:

> <Authentication with OAuth 2.doc><Authentication with OAuth 2.html><Authentication with OAuth 2.pdf>_______________________________________________
> OAuth mailing list
> [email-masked]

---

From: Hans Zandbelt <[email-masked]>
Date: Thu, 16 Oct 2014 23:23:11 +0200

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).

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 17 Oct 2014 13:25:50 +0100

+1. I'm finding this write-up summarizing the "OAuth2 and 
Authentication" 'situation' perfectly. It does help.

Minor suggestions/questions:
- might make sense to point out that an id_token can be linked to the 
access token (via at_hash), thus confirming both tokens came from the 
same AS
- should a 2-way TLS mentioned as a possible approach for mitigating the 
'injection of the token' attack ? I guess it won't scale really well but 
IMHO it is a useful mechanism nonetheless
- should a few words be reserved for the client credentials flow - this 
is of course not a mainstream OAuth2 nor its related to OIDC but it is 
all about the authentication IMHO, the clients get their tokens by 
simply getting authenticated, and as far as legacy (code) clients are 
concerned they 'migrate' from sending the name/password to the resource 
endpoint on every request ?
- IMHO it would be useful to mention that OIDC RP can help non-OAuth2 
servers, i.e one does not have to write an OAuth2 client web application 
to get the benefits of the OIDC-driven auhentication

Thanks, Sergey

---

From: "Richer, Justin P." <[email-masked]>
Date: Fri, 17 Oct 2014 13:33:25 +0000

On Oct 17, 2014, at 8:25 AM, Sergey Beryozkin <[email-masked]> wrote:

> +1. I'm finding this write-up summarizing the "OAuth2 and Authentication" 'situation' perfectly. It does help.
> 
> - might make sense to point out that an id_token can be linked to the access token (via at_hash), thus confirming both tokens came from the same AS

Seems a reasonable point, I can add that.

> - should a 2-way TLS mentioned as a possible approach for mitigating the 'injection of the token' attack ? I guess it won't scale really well but IMHO it is a useful mechanism nonetheless

It doesn't actually help in this case, since if the client is checking the server's certs that should be OK (or as OK as TLS can get). The real attack comes from someone handing the token to an application through a mechanism other than the return from the token endpoint, and I've seen a handful of applications that pass around the access token to themselves  through internal callback mechanisms that are a bit more exposed than they ought to be. 

> - should a few words be reserved for the client credentials flow - this is of course not a mainstream OAuth2 nor its related to OIDC but it is all about the authentication IMHO, the clients get their tokens by simply getting authenticated, and as far as legacy (code) clients are concerned they 'migrate' from sending the name/password to the resource endpoint on every request ?

The client credentials flow has nothing to do with user authentication, which is why it's left out of OIDC. There might not even be a user in this flow (and it's generally assumed that there isn't).

> - IMHO it would be useful to mention that OIDC RP can help non-OAuth2 servers, i.e one does not have to write an OAuth2 client web application to get the benefits of the OIDC-driven authentication

I don't understand what you're saying here. In order to make an OIDC RP, you need to write an OAuth2 client. That's by design.

 -- Justin

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 17 Oct 2014 14:51:32 +0100

Hi,
> It doesn't actually help in this case, since if the client is checking the server's certs that should be OK (or as OK as TLS can get). The real attack comes from someone handing the token to an app…
OK, I understand
> The client credentials flow has nothing to do with user authentication, which is why it's left out of OIDC. There might not even be a user in this flow (and it's generally assumed that there isn't).
Yes, it is not part of OIDC but it is still the authentication of the 
client that is effectively a resource owner, no human user is involved 
but IMHO it's still very much the authentication. Exactly what the coded 
clients do today in non OAuth2 client-server communications, except that 
in this case the name/password is offered only once to AS.
May be it was not what this flow was envisaged for originally but I do 
like it for the reasons outlined above, specifically it can help the 
legacy/traditional clients to 'join' the OAuth2 AS infrastucture

> I don't understand what you're saying here. In order to make an OIDC RP, you need to write an OAuth2 client. That's by design.
OIDC RP is a client. But this RP doe snot have to be collocated with the 
OAuth2 client which actually does some application specific work, right ?
I.e OIDC RP facilitates the OAuth2-based authentication mechanism but 
the server 'protected' by this RP which would work with the 
authenticated user does not have to be OAuth2 client, do you agree ?
If OIDC RP could only be used alongside OAuth2 clients then it would 
limit its usefulness IMHO

Cheers, Sergey

---

From: "Richer, Justin P." <[email-masked]>
Date: Fri, 17 Oct 2014 14:09:56 +0000

> Yes, it is not part of OIDC but it is still the authentication of the client that is effectively a resource owner, no human user is involved but IMHO it's still very much the authentication. Exactly what the coded clients do today in non OAuth2 client-server communications, except that in this case the name/password is offered only once to AS.
> May be it was not what this flow was envisaged for originally but I do like it for the reasons outlined above, specifically it can help the legacy/traditional clients to 'join' the OAuth2 AS infrastructure

But it's not authentication of the *user*, which is the whole point. When the client authenticates on its own behalf, you have no idea who the user is or if they exist. It's irrelevant to the user authentication flow. If you're looking for pulling legacy clients in, the "password" flow is better for that, but OIDC didn't profile it because people really shouldn't be using the password flow except in very limited use cases in the first place. 

> OIDC RP is a client. But this RP doe snot have to be collocated with the OAuth2 client which actually does some application specific work, right ?
> I.e OIDC RP facilitates the OAuth2-based authentication mechanism but the server 'protected' by this RP which would work with the authenticated user does not have to be OAuth2 client, do you agree ?
> If OIDC RP could only be used alongside OAuth2 clients then it would limit its usefulness IMHO

But the OIDC RP *is* an OAuth Client, so I still don't get what you're saying. Sure you can have OAuth clients that *aren't* OIDC clients, but you can't have an OIDC client that isn't also an OAuth client because OIDC is built directly on top of OAuth.

 -- Justin

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 17 Oct 2014 15:57:35 +0100

Hi,
> But it's not authentication of the *user*, which is the whole point. When the client authenticates on its own behalf, you have no idea who the user is or if they exist. It's irrelevant to the user…

I did get that. See the notes are about "OAuth2 & Authentication", so I 
thought it would not only be about the human user being authenticated 
via OIDC.
OAuth2 has different flows with some of them requiring no human user 
being around, and the client_credentials flow is all about 
authenticating the client giving the token back for it to access its own 
resources, except that not having to sent name/password every time.
This client does not need to be aware of any users because effectively 
this client is a 'user'.
If "OAuth2 & Authentication" implies the human user is involved then may 
be it would be clearer if the subject was reworded somehow...
Either way, if you reckon the client-credentials are out of scope then 
I'm fine with that, I guess keeping it focused on OIDC will help with 
the message

> But the OIDC RP *is* an OAuth Client, so I still don't get what you're saying. Sure you can have OAuth clients that *aren't* OIDC clients, but you can't have an OIDC client that isn't also an OAuth…

May be it is my language issues. I haven't suggested that OIDC can be 
implemented without it being OAuth2 client.

Consider this:

OIDC RP filter <-> non OAuth2 server

OIDC RP filter would do the OIDC thing (will act as OAuth2 client, 
return the user to OIDC IDP, validate the response) and then set the 
security context and let the user go to the non OAuth2 (client) server, 
with this server not being even aware that the OIDC flow has happened.

Am not making sense at all with the above ?

Thanks, Sergey

---

From: "Richer, Justin P." <[email-masked]>
Date: Fri, 17 Oct 2014 15:11:54 +0000

On Oct 17, 2014, at 10:57 AM, Sergey Beryozkin <[email-masked]> wrote:

> I did get that. See the notes are about "OAuth2 & Authentication", so I thought it would not only be about the human user being authenticated via OIDC.
> OAuth2 has different flows with some of them requiring no human user being around, and the client_credentials flow is all about authenticating the client giving the token back for it to access its own resources, except that not having to sent name/password every time.
> This client does not need to be aware of any users because effectively this client is a 'user'.
> If "OAuth2 & Authentication" implies the human user is involved then may be it would be clearer if the subject was reworded somehow...
> Either way, if you reckon the client-credentials are out of scope then I'm fine with that, I guess keeping it focused on OIDC will help with the message

Interesting, that's a misinterpretation that I didn't anticipate. I think I'm going to rename the whole page "OAuth and User Authentication" to avoid that.

> May be it is my language issues. I haven't suggested that OIDC can be implemented without it being OAuth2 client.
> 
> Consider this:
> 
> OIDC RP filter would do the OIDC thing (will act as OAuth2 client, return the user to OIDC IDP, validate the response) and then set the security context and let the user go to the non OAuth2 (client) server, with this server not being even aware that the OIDC flow has happened.
> 

I think I see what you're saying now -- you could have a client that authenticates the user through OIDC and also accesses some set of non-identity APIs through OAuth, and the two parts don't actually have to talk to each other. That's fine, but it's such a deep implementation detail that I don't think it helps the conversation that we're trying to have. Especially considering that the real problem stems from developers who do both authentication and authorized API access right side by side in the same code and get the two confused with each other. Is that a bit more clear?

Thanks for your input,
 -- Justin

---

From: John Bradley <[email-masked]>
Date: Fri, 17 Oct 2014 12:13:41 -0300

Are you saying that the OIDC filter/client can set session cookies in a domain that other web servers can use, so they don't have to have any direct knowledge of Connect.

I suspect that is a common practice in many SSO implementations.   It is true that not every web server needs to implement connect itself for SSO.

John B.

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 17 Oct 2014 16:39:14 +0100

Hi,
> Interesting, that's a misinterpretation that I didn't anticipate. I think I'm going to rename the whole page "OAuth and User Authentication" to avoid that.
To be clear, the notes did not confuse me :-), it is obvious they are 
about having the user involved in the authorization code/implicit flows 
involved, I just thought may be the doc can be enhanced further to cover 
various OAuth2 situations where the 'authentication' is involved.
Yea, "OAuth2 and User Authentication" is a good subject name IMHO
> I think I see what you're saying now -- you could have a client that authenticates the user through OIDC and also accesses some set of non-identity APIs through OAuth, and the two parts don't actua…
Not quite :-), actually, this is a good point about the OIDC filter 
being possibly separate from the 'actual' OAuth2 client web app 
expecting an authenticated user, as it happens I'm wondering right now 
how I can get it implemented so that a boilerplate client code stays 
clear of dealing with authenticating the user.

But you are right, I do refer to a case of the OIDC filter/RP being 
'separate' except that for the purpose of this discussion I'm referring 
to a case where it protects a non OAuth2 server, i.e, the server which 
does not know what OAuth2 is. That is, I think OIDC RPs can be used to 
protect all types of servers, some of them will be OAuth2 clients on 
their own, some of them will be web apps which do not do OAuth2 at all.
Perhaps it is off-topic for the actual notes, might deserve some note 
elsewhere...

When I go to the OIDC site, I see it talks about the evolution from 
OpenId 2.0. The latter could have been used to log in users into non 
OAuth2 servers. The OAuth2-centricity of OIDC is its 'implementation 
detail'. But when I read about it it's all only about OAuth2 which is 
fair enough, OIDC is perfectly aligned with OAuth2, but if we have 
developers who have written non-OAuth2 servers protected by 'legacy' 
IDPs then they should know they won't have to turn their non-OAuth2 
servers into OAuth2 client web apps to have the authentication supported 
by OIDC - a non collocated OIDC RP would help them to migrate to OIDC 
with their non-OAuth2 servers continuing doing whatever they do unchanged.

Sorry I may've lost everyone with my reasoning above :-)

Many thanks
Sergey

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 17 Oct 2014 16:42:45 +0100

Hi
> Are you saying that the OIDC filter/client can set session cookies in a domain that other web servers can use, so they don't have to have any direct knowledge of Connect.
Yes. It is a pity I was not able to express myself with a single 
sentence like you offered above :-)
> I suspect that is a common practice in many SSO implementations.   It is true that not every web server needs to implement connect itself for SSO.
Right; I guess it would make sense to make it a bit more obvious in some 
docs, may be in Opend id Connect Intro or similar

Thanks, Sergey

---

From: Hans Zandbelt <[email-masked]>
Date: Mon, 20 Oct 2014 20:42:05 +0200

or pointier: there are OAuth 2.0 deployments today that offer login 
semantics because they have a REST/JSON user profile API that can be 
accessed using the AT that was obtained in a code flow; should that be 
acknowledged in the doc?

Hans.

On 10/16/14, 11:23 PM, Hans Zandbelt 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...
>>
>>
>>> "These recipes each add a number of items, such as a common profile
>>> API, to OAuth to create an authorization protocol."
>>>

---

From: "Richer, Justin P." <[email-masked]>
Date: Mon, 20 Oct 2014 19:04:21 +0000

This is actually one of the sticky bits that I've tried to address in the document itself -- I've seen apps that assume that if they're given an access token that can be used to fetch profile information then the user is actually there. This isn't actually a guarantee, but it's commonly true enough that developers get lazy and rely on it. 

 -- Justin

On Oct 20, 2014, at 2:42 PM, Hans Zandbelt <[email-masked]> wrote:

> or pointier: there are OAuth 2.0 deployments today that offer login semantics because they have a REST/JSON user profile API that can be accessed using the AT that was obtained in a code flow; should that be acknowledged in the doc?
> 
> Hans.
>

---

From: Hans Zandbelt <[email-masked]>
Date: Mon, 20 Oct 2014 21:20:59 +0200

My point is that it *is* a guarantee if the AT just came to the client 
in a code flow; I don't see a problem with that although clients have to 
be aware of what they're doing and not allow any other flows for this.

Hans.

---

From: "Richer, Justin P." <[email-masked]>
Date: Mon, 20 Oct 2014 19:29:02 +0000

Right, when you get the AT directly from the token endpoint and it's good for something, that will *probably* tell you the user is logged in. This is assuming that the authentication context can also be communicated, audience restrictions can be communicated, and all the other good stuff the document talks about. A real problem tends to stem from clients who will take access tokens from various public endpoints and use them directly (implicit clients are inherently open to this problem). Or that an access token can have a life long past the authentication event, so if a client saves the access token off someplace, does a bunch of work, then finally asks "Who's there?" and makes the user info API call, it's going to get info but not necessarily what it assumes. 

Really, all of this is why there's the ID Token and the Signed Request components in OIDC and FBC, respectively. Plus you don't always want the profile information on every request, so having something the client can read directly saves a round trip to fetch data it doesn't really want. Having the separation between the authentication context and the profile information really does make the code paths a bit simpler.

 -- Justin

On Oct 20, 2014, at 3:20 PM, Hans Zandbelt <[email-masked]> wrote:

> My point is that it *is* a guarantee if the AT just came to the client in a code flow; I don't see a problem with that although clients have to be aware of what they're doing and not allow any other flows for this.
> 
> Hans.
>

---

From: Phil Hunt <[email-masked]>
Date: Mon, 20 Oct 2014 13:06:23 -0700

The problem is you are making a lot of assumptions that may or may not be true - they are just generally true.

The right to access may be granted without even authenticating a user. For example, a web resource might allow any registered client to have acess to any resource.  Only certain scopes require consent. For example, readProfile is public, but updateProfile is restricted.

The presumption that receiving an AT would be entirely false in this situation as the user was never even authenticated because consent was not required.

We’ve also talked about how access to a resource /Me also binds the name of the authenticate user to the access request.  If the API does not have a /Me endpoint, than the identity information you are requesting could be for any person the AT is allowed to see.  This creates another “hack” point where clients could be fooled to thinking they have authenticate a particular person when in fact all they have proven is access it a particular resource not necessarily the user is valid.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: John Bradley <[email-masked]>
Date: Mon, 20 Oct 2014 18:22:16 -0300

Even in the simple code use case there are things that need to be profiled.

1. The resource owner must be the only one who can grant AT for the profile resource.  (This may not be true for general purpose API or require a special api call)

2. OAuth allows a fair flexibility around redirect uri matching with confidential clients.  "code" can be intercepted and replayed to the client.   The redirect_uri matching rules need to be tightened up like Connect has done.   Oauth assumes that a third party can't use code to get to the protected resource because of the client secret,  for an identity service replaying code to the client is an attack.
(Oauth mitigates this by sending the redirect_uri in the request to the token endpoint,  but exact matching of that URI including query parameters is not necessarily treated with sufficient diligence by implementations only thinking about authorization.

3. There is no real authentication context so the clieent has no idea when the user authenticated or how etc.

There are probably other things but re-using an existing data API for authentication may go seriously wrong even in this case without a fairly sophisticated analysis. 

John B.

---

From: Bill Mills <[email-masked]>
Date: Mon, 20 Oct 2014 21:32:45 +0000 (UTC)

+1 on OIDC being an authentication solution, OAuth is authorization and the pitfalls of using it as authN have been well hashed out.  If people are still getting it wrong more guidance is needed. 

     On Monday, October 20, 2014 1:07 PM, "Richer, Justin P." <[email-masked]> wrote:

 -- Justin

---

From: Hans Zandbelt <[email-masked]>
Date: Mon, 20 Oct 2014 23:47:16 +0200

I agree with the considerations, but I also feel that they are generally 
true for 3rd party clients to services where the resource owner has an 
account/profile.

1. typically the case for a /me (read) profile API
2. best practice after earlier exploits
3. the "code" has a recommended lifetime of 10 minutes by spec

I also agree that because there are a number of conditions that need to 
be met (even though generally true as Phil says) as such it may be wise 
not to spell out this scenario with the risk of becoming "best" practice.

I am not really advocating for this anyway, it just struck me that 
authz/authn really overlap here (admittedly as a "special" case).

Hans.

---

From: "Richer, Justin P." <[email-masked]>
Date: Mon, 27 Oct 2014 23:21:21 +0000

I've been incorporating peoples' feedback into the proposed oauth.net page, and the current state is here:

https://github.com/jricher/oauth.net/blob/authentication/articles/authentication.php

Commentary has slowed down and I think the document's in reasonable. I would like to publish this as a draft version on oauth.net in the very near future (like, this week), so get comments and feedback to me on this soon. I'm going to be at IIW all week if anyone wants to back me into a corner and talk about this.

 -- Justin