I'm reading about refresh tokens: https://auth0.com/learn/refresh-tokens/. I'm building an Authentication Server (AS) myself.
To get a refresh token from a email/password authentication, the client app sends 4 pieces of information:
client id
client password
user email
user password
My question is: how does the AS pass the client id and password to the client app?
My first idea: is the password generated randomly beforehand and hard-coded in every client app? Why is the client id needed then?
My 2nd idea: the client app on first startup hits the AS to gets its client id/password, and uses this pair to get all future refresh tokens. But it isn't secure, as any hacker can hit this same endpoint.
Help appreciated.
Related
I am building a REST API as the backend for a mobile app. I would like to check if the requests made to the API are coming from our mobile app. However, the API will require end users to login in order to access certain endpoints.
My questions is, how could I authenticate all incoming requests to make sure they are coming from our own app, while also authenticating the end users for some requests?
I was thinking of sending an API key with all requests in the Authentication HTTP Header to authenticate the mobile app, and (separated by a comma) also send along a JWT for authenticating the end-user. While this could work, it seems a bit "hacky".
What is the standard way of authenticating both the mobile app and the
end-user of the mobile app at the same time?
Using an application token and a user-specific session token is one method of separating authentication of the two. The application token would be unique for your application, and should be obfuscated so that inspection of the client's binary would not lead to easy detection of the token. The user-specific session token should be generated when the user is logged in. The client adds this user session key to future API calls, the server will check if the session key is valid, and can use it to look up any session state stored for the client.
However, optimally, you would implement the full oauth2 spec. as outlined in this ultimate guide to mobile API security:
Here’s how OAuth2 token authentication works from a user perspective
(OAuth2 calls this the password grant flow):
A user opens up your mobile app and is prompted for their username or email and password.
You send a POST request from your mobile app to your API service with the user’s username or email and password data included (OVER SSL!).
You validate the user credentials, and create an access token for the user that expires after a certain amount of time.
You store this access token on the mobile device, treating it like an API key which lets you access your API service.
Once the access token expires and no longer works, you re-prompt the user for their username or email and password.
What makes OAuth2 great for securing APIs is that it doesn’t require you to store API keys in an unsafe environment. Instead, it will generate access tokens that can be stored in an untrusted environment temporarily.
This is great because even if an attacker somehow manages to get a hold of your temporary access token, it will expire! This reduces damage potential (we’ll cover this in more depth in our next article).
I want to build a REST API which will be used by both mobile app and also a website. I was wondering how would I go about implementing a simple login system for users?
For a simple website, after checking the username and password, one could set a SESSION variable and have the user "logged in".
Now, REST is stateless so I suspect that the above is not the way to go about. I thought that a possible solution would be to have the server generate and return an access token each time the user logs in, and the client will need to attach this access token to every subsequent request to access protected endpoints.
Is the above a viable solution or what is the industry standard for something like this?
(I found OAuth 2.0 to be overkill, but I could be wrong)
There are several token authentication schemes, but if you're looking for the industry standard, then JWT (JSON Web Token) is the way to go. Here's how the process usually goes:
Client sends his credentials (e.g. username and password) to the server.
The server verifies that the credentials are correct, generates a JWT and returns it to the client. Client saves the token in e.g. localStorage.
For each subsequent request, the client will attach the JWT as a part of the request (usually in the "Authorization" header).
Server will be able to decode the JWT and decide if the client should have access to the requested resource.
Now, some interesting features of JWT come from the fact that there is data encoded in it. Some of it everyone can decode, and some only the server can decode.
So, for example, you could encode the user's id and profile picture in the JWT so that the client can use the data from it, not having to do another request to the server to get his profile.
JWT has embedded info about expiration. The server can set the expiration time.
Another cool thing about JWTs is that they are invalid if changed. Imagine you stole someone's token, but it's expired. You try to change the expire information inside the token to some time in the future, and send it to the server. Server will deem that token invalid, because the contents doesn't match the signature attached, and a valid signature can only be generated by the server.
I'm running a mock expressjs server in the back, and ember (ember-simple-auth) on the front with the ember-simple-auth-token addon. I'm using JWT tokens. I'm trying to decide whats the best way to send my user information. Usually when the user submits their credentials I create a new token, store a copy of it in the database (I'm using mongodb), send it to the frontend and then use the token to fetch information user information. I have a /auth/token (which authenticates and sends the token, makes a copy and stores it in the database) & /current_user route which gets called on the initial login, which uses the token and fetches the user info.
Is it better to simply send the user info in the initial payload of the token over having a separate route? Should I be storing a copy in the database in order to do a comparison and retrieve user information?
Also what are the advantages of a token refresh?
you are using Jwt-Auth for authentication.
-According to my knowledge after sending the user credentials u will respond with the token if credentials are correct otherwise send error.
-why are you saving the token in db ?.
you will send token to client (stateless). If client requests for data then we need to check for token. if it validates then return proper response otherwise return token error.
-why you need token refresh?
for security purpose. After response every time change the token.
TTL your token will be valid for some time (say 60 mins). after that it will be invalid.
This is how JWT works.
I'm new to ReST and am implementing a ReSTful token authentication, trying to use Django-Rest-Framework JWT, in a mobile web app in the standard way
client sends credentials
server verifies and sends token and expiration date back. Deletes token from db
client calls refresh token when user makes request and token is about to expire
on client request, server verifies token signature
on expired token mobile app logs user out. Mobile app checks expiration not server
I decided to make the mobile app check the expiration date since I read that is ReSTFul, and the server checking it requires it to store tokens which is not ReSTful
I have a few security questions regarding the above implementation:
1) Doesn't obtaining one token give the attacker complete access to the user's login no matter how many token refreshes happen?
Even if it's over https, let's say by some means a token was retrieved by an attacker, i.e. ssl interceptor proxy.Obviously the mobile application won't allow them to login, but they can grab data by calling the api with the token through any HTTP client.
2) What is the purpose of having refreshing tokens in the first place if the server considers all of them as valid?
There seems to be no forward security in this.However, if the server stored the tokens and kept their expiration dates, a complete user compromise would be stopped, but not a per session compromise. Obviously with an SSL interceptor they could still compromise the user, but would need to catch every login. However that implementation is not ReSTful.
First of all, expired tokens are valid tokens, but you can check if token expired or not, before taken any action, and reject the ones expired. There are several things you can do to increase the security of your app:
You can add the hashed password inside token. Therefore if user lost his/her mobile, when password changed in another device, you can reject the tokens with old password hash.
This one is not totally restful, but not that bad as well: you can add a table called revokedTokens in db which keeps track of id of tokens (obviously you should add it to token) user revoked, if you receive request with that token later on, you can reject it until it expires. when it expires you can remove from the table, as expired tokens won't be a problem anyway.
You can add the device's host name when user logs in to the token, and compare it with the request's host name, to have additional layer of security for ssl interceptor attack. Yes, it's not total protection, but still a bit better, as attacker needs to change his/her host name in addition to sending the token from another device.
Hope this helps.
I want to create an app that will authenticate with my server using oauth.
My question is how will this work?
My client side will communicate using HTTPS with Facebook and get an Access Token. Then it should send it to my server side to authenticate? My server should save the token in the db? How it can validate the token?
how will this work. ?
When the client needs authorization to access some information about the user, the browser (user agent) redirects the resource owner to the OAuth authorization server. There, the user is faced with an authentication dialog (this dialog is not shown if the user is already authenticated), after which he or she is presented an authorization dialog explaining the permissions that the client is requesting, the information that it needs to access or the actions that it needs to do on his or her behalf.
Access Token should send it to my server side to authenticate? or server should save the token in the db?
From what you describe I'd suggest to use a server-side login flow.
-so that the token is already on your server, and doesn't need to be passed from the client. If you're using non-encrypted connections, this could be a security risk.
(after a user successfully signs in, send the user's ID token to your server using HTTPS. Then, on the server, verify the integrity of the ID token and retrieve the user's ID from the sub claim of the ID token. You can use user IDs transmitted in this way to safely identity the currently signed-in user on the backend.)
-See
https://developers.facebook.com/docs/facebook-login/manually-build-a-login-flow/v2.2#login
How to validate token ?
you can follow this link , you will get your step by step solution for an app.
Facebook access token server-side validation for iPhone app