How does OAuth work?

54 views

Note I’m specifically I’m asking about how it works, not what it is. Does it use PKI? How? What goes on when someone authenticates?

In: 0

Instead of requiring you to send your credentials to EVERY system you want to log into, them now having your password and needing to be able to talk to the system that has your credentials stored (usually a dedicated tool for housing user details and roles) to verify that your password is CORRECT, OAuth allows you to only give your credentials to the identity provider, who then returns you a portable token proving that you’ve logged in and containing a list of the things you’re allowed to do.

Instead of sending your password everywhere, you just pass along that token.

Instead of validating your login every time, each system you access can simply check your token and talk to the IDP to grant you access without requiring another login!

Note that OAuth is just a method to authorize an action by a service, with the result being a random ‘access’ token that allows you to access the service (usually just passed with the request). If you login using a service, all they typically want to access is a unique identifier in order to know who logged in. There are other types of tokens, but they are mostly used to get a new ‘access’ token – saved to databases and used for ‘long term’ access to a user login (see https://www.reddit.com/prefs/apps/ for the apps that have been given access to this ‘refresh’ token; revoking access stops the app from getting new ‘access’ tokens).

I am going to call the process by which you get the access token the ‘login’ step.

There are (at least) 2 main types of ‘logins’ done with OAuth: human user logins and computer user logins.

Computer user logins are ones where one server needs to talk to another server and there is no human to put in the login details. They can use PKI to sign and verify the identity of the requester, or they can just use ‘username:password’ (encoded as base64 to make it url safe) as the login token. You usually have to go to a service and not only register your service (e.g. “Portablejim’s login service”) but also the username.

Human user logins are ones where a server needs to use a human’s login details. When you register a service (e.g. “Portablejim’s Login Service”) you get given a client id and a ‘private’ token. You send the user to a URL that contains not only the client id but also a callback/redirect URL – one to redirect the user to after they login to the other service. (For google’s API the URL is basically ‘https://accounts.google.com/o/oauth2/v2/auth?clientid=myclientid&redirect_uri=https://example.com’ – I am skipping other additional bits, such as the parameters that say what sort of access is needed). When the user has logged in, they will be directed to the specified redirect URL, but with a random token in the parameters. The random token plus the private token are then exchanged for the actual access token (this is a server-to-server request). If you have used the login service before and the service is not keeping a long-lived token around, services may just redirect you to your callback URL, that when combined service you came from adding a redirect from the callback URL to it’s default page for logged in users, there are a few redirects (oauth login -> callback -> ‘logged in’ page).