Subject: [OAUTH-WG] End User Authentication using OAuth 2.0

From: Justin Richer <[email-masked]>
Date: Sun, 02 Nov 2014 23:30:38 -0500

As of earlier this evening, I've published the article that we've been 
working on about dealing with OAuth and end-user authentication. It's 
available here:

http://oauth.net/articles/authentication/

Huge thanks to everyone who commented on the text, both here on the list 
and last week at IIW. If there are edits to be made, either reply here 
or just make a pull request directly from GitHub. It's not an RFC, we 
can keep editing it. :)

In the process of putting this together for the site, I also created an 
"Articles" structure on the site so that if there are other topics we 
want to add, we (the community, not just the WG) can do so.

  -- Justin

---

From: Sergey Beryozkin <[email-masked]>
Date: Mon, 03 Nov 2014 11:00:31 +0000

Hi Justin,
> or just make a pull request directly from GitHub. It's not an RFC, we
Thanks for your help. Nice article indeed.

Something I've been planning to ask, sorry if it is off topic - may be 
it is better be posted elsewhere, just let me know please, the actual 
question is here for now:

OIDC can help Clients ask for the permissions to access the user's 
identity info plus some other info this Client actually needs to have in 
order to do something useful for the user at the same time. This is one 
of the distinguishing features of OIDC. I guess a good example would be 
an "openid profile calendar" scope, where a 'calendar' scope is about 
the Client being able to access the user's calendar.

What is not clear here is how it all fits into a typical sign on process 
followed by some service offerings. Suppose we have a ReservationService 
Client. When the user goes to the ReservationService's web site which 
supports a sign on via Google or other OIDC IDP, the user is obviously 
not redirected immediately to Google with "openid profile calendar" 
scope already set, the user would see some kind of Sign On Welcome Page 
first.

After the user completes the sign on process, the OIDC RP would validate 
id_token, may be get UserProfile, and then the session would begin and 
the service will offer the user an option to do some reservation which 
requires a Client to have an access token allowing it to get to the 
user's calendar.

One question here is really how it can be aligned with the OIDC feature 
allowing IDP/AS to ask during the user signing on with OIDC IDP for 
multiple permissions such as "openid profile calendar" at the same time.

I can only imagine that for this to work, the Sign On Welcome Page would 
already have a script with the "openid profile calendar" scope set, so 
when the user clicks some 'Sign In' button, the user would be asked at 
the OIDC IDP site to let the Client access "the profile info and the 
calendar info".

That is probably how it should flow. If so, then it is obvious OIDC RP 
should share a session state with the actual ReservationService client 
because a signed on user redirected back to it from OIDC IDP/AS won't 
have reserved something for it straight away, ReservationService would 
only now ask the signed on user some questions re the reservation 
details. And the only way ReservationService can complete the 
reservation is for it to use an access token OIDC RP received when it 
itself accessed the OIDC UserProfile endpoint.

Effectively we are talking about OIDC RP sharing an access token via a 
session state with the Client in this case. Note I'm referring to the 
case where the Client wants to ask both OIDC related and its own 
application specific permissions such as "openid profile calendar" and 
the fact that the end user would be typically be exploring 
ReservationService site in two steps, sign on first, ask for the 
reservation service next.

Does it make sense at all ? If yes, what, if anything, can be 
recommended in this case where an access token is to be shared between 
OIDP RP and the actual Client ?

Thanks, sorry for a long message

Sergey

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Antonio Sanso <[email-masked]>
Date: Mon, 3 Nov 2014 19:27:46 +0000

nice stuff Justin.
Little nitpicking: is just me or this sounds a bit weird "signed by the identity provider's public key” ?

regards

antonio

On Nov 3, 2014, at 5:30 AM, Justin Richer <[email-masked]> wrote:

> As of earlier this evening, I've published the article that we've been working on about dealing with OAuth and end-user authentication. It's available here:
> 
> Huge thanks to everyone who commented on the text, both here on the list and last week at IIW. If there are edits to be made, either reply here or just make a pull request directly from GitHub. It's not an RFC, we can keep editing it. :)
> 
> In the process of putting this together for the site, I also created an "Articles" structure on the site so that if there are other topics we want to add, we (the community, not just the WG) can do so.
> 
> -- Justin
>

---

From: Antonio Sanso <[email-masked]>
Date: Mon, 3 Nov 2014 19:30:35 +0000

ops sorry forget about it… of course this is correct… For some reason I read "signed with the identity provider's public key” :)

regards

antonio

---

From: John Bradley <[email-masked]>
Date: Mon, 3 Nov 2014 17:07:25 -0300

Strictly speaking the JWT is signed by the  "iss"  identity provider's private key and validated by the client using the identity providers public key.

Though lots of documents talk about signing with "public keys" using the term more conceptually. 

You could say "signed by the private portion of the identity providers public key pair"   but it is a bit awkward.

John B.