Hello!
I’m working on a rest api for a mobile app, where authentication is done via an Authentication: Bearer <access_token> for every request to rest api.
Initially, I’m able get the access token and refresh token from auth server(which was written in phoenix). In the access token and renew token, user details are embedded through some salt key… I’m able to verify and retrieve user info from the tokens on auth server using some cryptography verify function.
My actual question is, how should I verify the bearer token on resource rest api server? Should I share the same salt key that was used in auth server to verify and then send user related data?
I would grateful if somebody could help me understand the concept. Thank you!
from my experience I would not recommend to share the key to other services. One of the reason is if you need to update the key signing the token it will have to be propagated across. If you are concerned about sharing the key itself then use a Public Private key signing. In a gateway pattern the entity would make the call to the auth server for you and verify the token before passing you so making a call to the auth server to verify is a valid approach to take in order to not share the key
I thought about it the same.
What is the known/general way of doing authentication and authorisation for mobile apps and api’s?
(I don’t want to reinvent the wheel, I just want to conform)
If you look at how Google, Apple, Firebase give you an access token it could be considered a general practice. Once you log in they would provide you with JWT thay can be validated using JWKS in simple words it can be verified using the public key as the token is signed by their private key. This is the case when you give away a token to someone who doesn’t need to reach out to you for verifying the authenticity of the token but can do it on their end. but if you use non public-private mechanism the only the issuer can verify the token and you have to send it over to verify. You can cache the call till the token expiry if its a JWT as its JWT come with their own expiry duration and are not generally meant to be revoked.
1 Like
I read somewhere that using JWT isn’t that secure… currently I’m reading this post on StackOverflow. I’ll see if it helps.
JWT aren’t meant to manage session where you are looking for logout option. You will find a lot of debate over how good are JWT but one thing most people will agree on is that its not for session management where you have to store the token to keep track if someone is still logged in. The good part of JWT is its ability for others to verify the token you issued if they have the key and you can embed information in it. If you look at the Guardian elixir library they have Guardian DB project which allows you to store the JWT in a DB but at the same time they mention if you are storing JWT in DB you probably don’t need JWT
Yeah, you’re right!
I’ve been stuck with this for the past few days. Your posts are quite helpful in understanding.
For example, how is twitter, instagram apps are able to maintain the session using the token, do they use JWT’s as well?
I am not sure how Twitter or Instagram is doing it but they all have different approaches. Google gives you a JWT that you can exchange from your service for an access token to allow your app to have access to your APIs while Facebook doesn’t give you a JWT but a regular token. If you are implementing the social logins they are meant for authenticating user owns a particular account and agrees to share certain info with the service he is about to log in to. Once you get the token you would generally exchange it for an access token hence the token from Google etc doesn’t have to be long lived and doesn’t cares for a session management. The responsibility of session management relies on you and not on their token. Their token are usually valid for 30 minute or so and without a refresh token. With JWT a “session” access to service is extended using a refresh token. For how to revoke a session with a JWT there is a split opinion over should a service maintain a blacklist or a whitelist for the token validity to allow or disallow access.
