To fully understand it, let’s look at the full lifecycle of an access token in PropelAuth for a very typical application with a frontend and backend:
Our goal at PropelAuth 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 Bob logs in with PropelAuth’s Hosted Pages.
- User Bob is redirected back to your application.
- Your frontend makes a request to PropelAuth, checking if the current user is logged in.
- PropelAuth sees that the current user is logged in, knows that it’s Bob, and returns an access token for Bob. This access token is unique to Bob and must remain secret.
- When your frontend needs to make requests on Bob’s behalf (e.g. fetching/setting data for Bob), it will include that access token in the request.
- Your backend is able to verify that the access token is valid and that it belongs to Bob. It’s able to do this because it has a public key provided by PropelAuth.
Technical Details (JWTs)
PropelAuth uses JSON Web Tokens or JWTs for our access tokens. At a high level, a JWT is a JSON payload that is signed, with some standardized fields.
There are a lot of different ways to create a JWT, including different algorithms to sign it (symmetric or asymmetric) and different fields to verify, however, PropelAuth’s libraries and hosted services hide that complexity.
PropelAuth uses an asymmetric signing algorithm which uses one private key to sign the tokens and a different public key to verify them. PropelAuth manages the private key used to sign the JWT and your libraries will use the public key to verify the JWTs are valid.
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, if necessary.