Token Based Auth
A token is a piece of text that states what a user can do, signed by the server with its private key.
- The user sends the username and password to the server, which checks them against its database.
- The server sends back a token: signed text showing all the permissions, such as Gaurav can create and delete documents.
- The user sends the token along with each request. The server decrypts it with its public key, which proves that the text came from the server, and does not take the password again.
The private key is a number never shared with anyone, and the public key is a number everyone knows. The signed text is gibberish, and guessing the private key is computationally too difficult.
A token does not protect against replay attacks: a person who steals it acts in the user's name.
Logging out invalidates the token. The server stores the time of the last logout, so a token from 9 a.m. is no longer valid after a logout at 10:30 a.m.
SSO and OAuth
Single sign-on (SSO) moves authentication to an external service, and OAuth gets authorization on an external system.
SSO comes from the SAML protocol. Gaurav has an account on Uber, so Uber checks his credentials and sends InterviewReady a token. On every request InterviewReady decrypts the token with Uber's public key and reads the permissions. Token generation has moved to an external system.
After a layoff, Uber answers no for that user and the access ends. The benefit is for companies that want total control of their users.
OAuth is the opposite of SSO:
- InterviewReady asks Google for permission to add, delete and modify events in Gaurav's calendar.
- Google asks the user on its sign-in screen.
- On a yes, Google gives InterviewReady a token to use on each change.
- When the user revokes access, Google invalidates the token and the requests fail.
OAuth is an authorization system, but nearly everyone uses it for authentication. InterviewReady asks Google for the name and profile photo of a person, and treats the permission as authentication.