Under the hood
An access token is a string or certificate that uniquely identifies a user. It is called an access token because it is used to give your users access to your product.
To fully understand it, let’s look at the full lifecycle of an access token in Authdog for a very typical application with a frontend and backend:
Our goal at Authdog is to provide a developer friendly authentication experience. So, while this whole process might seem complex, we provide libraries that can reduce all six steps down to a few lines of code.
- User A logs in to your app through Authdog managed pages.
- User A is redirected back to your app by Authdog along with an access token (url hash in dev, secured cookie in production).
- Your app sends the token to Authdog services, to check if the current user has a valid session.
- Authdog returns the user’s data in the response.
- When your app needs to make requests to your backend server, it sends the access token along with the request.
- Your backend server checks whether the access token is valid. If it is, it returns the data that the client app requested.
JSON Web Tokens
Authdog uses JSON Web Tokens (often referred to as JWTs) to authenticate users and protect its resources.
Simply put, a JWT is a string that contains a JSON object.
This JSON object is JSON Web Token (JWT) that contains information about a user. This information can be verified and trusted because it is digitally signed.
JWTs are signed with a managed secret via Authdog. This secret is only known at the time of signin and never exposed publicly.
Authdog uses asymetric signing algorithms to sign JWTs, using a private key to sign and a public key to verify the signature (exposed via dedicated JWKS endpoint).
This approach has some key advantages like validating access tokens is fast, since your backend can do it without making any external requests. It also works well with microservices since each service can validate the token independently only relying on public key.