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