101 Introduction to OAuth2
Introduction to OAuth2
Tuesday 1B
Convener: Justin R.
Notes-taker(s): Anik
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
OAUTH
The presenter has written a book on OAuth2. 39oauth2 OAuth2 in action.
A lot of OAuth out there right now.
What is OAuth?
- An Authentication method
- Token instead of actual credentials.
OAuth, acc to the spec, “authorization framework..” (Take from notes)
Letting 3rd party app get access on behalf on someone.
-not an authentication protocol
It’s a delegation protocol. Giving an app the permission to act on one’s behalf.
Traditional OAuth:
Resource Owner (RO). — has access to —> Protected resource (PR).
OAuth was designed for http.
- (Client app)
RO ——> CA ——> PR
One way: to give CA, the actual credential
- - no way for PR to identify who is asking for it.
- - no way for access control (read only)
- - only way to remove access is to change password
- + simple to build
- - credentials given to CA can be used maliciously.
Second way: In the enterprise world, a thing was described as “Client Key” . It hasn’t taken any consent from the user. No way for the PR to confirm it came from user.
Third way:
Special passwords to be given to CA.
+ nice and limited
+ access control is better
- usability sucks (user can’t remember all the passwords)
Example study: Google Subversion
Fourth way:
Fix usability
A new component: T (Authorization Server) to manage credentials, knows who we are, what we are delegating, who we are we delegating to. A special password called: Auth token.
OAuth uses http a lot, we need to know how http works. Http includes a lot of specialized info embedded into it, but people don’t speak http. So we need a thing called front channel communication. It works when a client (browser) wants to talk to AS. And As redirects the browser to C through to PR.
Downsides: Browser can leak info, we don’t have any control on it. OAuth tackles it by saying, Browser can do only specific thing at specific time.
When we are doing Auth flow. Traditionally all parties were web servers.
Front channel redirect:
ClientId, Scope (a bag of strings that gets passed around., defined by API)
We can start a session between User and AS, which warrants a login. AS knows who the user is, who the client is, what the request is (scope)
But still AS, can ask Client C wants access to PR, should we allow that?
Answer to whether one has used OAuth: is almost always yes.
Q : What’s Scope?
A: Any resources which will identify AS to the PR can be called a scope. In practice, each individual resource has a different scope.
Now User can confirm that she wanted to allow access, can have better access control.
Delegation is not completely independent of security, its a subset of it.
AS handles a major part of complexity of the protocol. Earlier a lot of complexity was supposed to be in C. But C only care about security only when it comes in their way. They all want it, but only to do what they actually want to.
Now, Browser knows which client to talk to. AS knows what scope the client is supposed to have. Even if a C is allowed to get that scope, user may still deny it
Q: How is the client id protected?
A: Its public.
Q: Can I use someone else’s client Id?
A: Yes, we don’t know what prevents us yet to come in this session.
AS takes in RO, C, PR and generates an Authorization code (AC) which is a random string.
User talked to As -> AS gives back a AC (front chanel redirect) -> User talks to Client and passes the AC -> C talks to AS (which only allows particular AC to particular clients)
AC is not enough on its own. There is a client secret (CS) given to C which needs to authenticate to AS. Which, in addition to AC, makes sure AS authorizes the call). CS is not known to the user.
Now AS replies back with an access token (T) back to C, which it passes to PR to show access. It is opaque to the client, so the client never gets to know what permissions were provided (it hopes it got what it asked for)
In all cases, Client is completely dumb. They will always say AuthToken doesn’t work in all failed cases (Not enough permission, token expired etc)
Criticism : AS is a single point of failure.
Defense: Its ok to have one secure single point of failure than having multiple places to make things wrong.
Through Open Auth, Client never gets to know anything about the user. It can do so through other additional info.
Optimizations:
- What if client is running inside the browser. Now “implicit flow” comes not picture, now no need of a Client secret. Its less secure, it beats cookies in security, but is susceptive to various attacks.
- API key can be used in applications directly. Instead of user’s password apps can use API keys
