Re: [OAUTH-WG] Report an authentication issue

[Justin Richer <[e-mail]>]

>
> 3)If I wanted to use OAuth, the client would send an authorization 
> request to the server's AS, which would authenticate the user of the 
> client, and ultimately result in the client possessing an 
> access-token.  My thinking is that this access token (let's assume 
> it's a JWT) would contain the user's identity, a statement of what 
> type of primary authentication was used (auth context), an expiration, 
> and an audience claim.  This sounds a lot like authentication to me, 
> and it's where I get confused.  Is it just because OAuth does not 
> explicitly define this?  Is there a threat in using OAuth as I describe?
>

You've hit on it here -- you're using OAuth *plus* a few other bits to 
accomplish this. Using a JWT lets you do things like signed tokens and 
audience restriction so that clients won't just take *any* token.

> 4)If I wanted to use Connect, well I'm not even sure how the id_token 
> as defined by Connect helps this use case.  The id_token seems to make 
> sense when the client is a confidential web server, but it's not clear 
> what an iPhone app would do with the id_token ... it's the server in 
> the backend that needs to authenticate the user, the iPhone app is 
> just an interface to talk to the server.  And it seems as I learn more 
> about connect that the id_token is not meant to be sent from the 
> iPhone app to the server, just the access token.  So it's really not 
> clear how Connect helps solve authentication for an iPhone client app 
> talking to a video server.  If I'm sending access-tokens, it's just 
> OAuth again.
>

Connect adds a few things on top of OAuth to make authentication 
possible, and one of these is the id_token. But what you're really after 
in your scenario isn't authentication at the RS per se -- it's 
authorization for accessing it.

  -- Justin