This is an architectural question related to the use of jwt.
When user logs in in my mobile app I generate a jwt. I do not know what strategy to follow when the same user logins on multiple mobile devices: to share the same jwt in all devices or to create a new jwt per device login?
Create a new token for each login.
apart from security issues, just not practical. To reuse tokens will need to store them on the server. This eliminates one of the advantages of JW : no need server space . What happens when a token is about to expire ? you issue a new JWT ? otherwise you will not be synchronized devices
Related
I'm working on a project that has the following requirement: Sessions should never last more than 90 days.
I'm also using Firestore, and by extension to authenticate users, Firebase Auth. I want to give access to Firestore to my android and ios clients, for 90 days maximum. After that duration the session should automatically expire.
I initially thought custom tokens were the solution, because I thought they were just a different term for ID tokens. But in reality they can be used to get a refresh token that never expires.
I therefore thought about managing the refresh tokens myself, by:
issuing my own refresh tokens
verifying their validity
creating a new custom token
exchange the custom token with an id token and refresh token on the back end
only return the ID token to the client
the client would give it to firestore.
I don't mind managing expiration and renewing the id token myself on the my back end.
Now my problem is that when I look at the official SDKs for firestore on Android and SDKs, none seem to allow for just attaching an id token to requests?
Is there a solution to my issue? Or maybe even a better approach?
Thanks!
I have an API service that is currently secured using JWT. I'm going to replace JWT with Identity Server 4 and secure my API with Identity Server 4. I had a custom way of generating JWT tokens (JWE). How can I replace JWT with Identity Server 4 without the current signed-in users to the site need to re-login?
Specifically, I wanna use the Skoruba Identity Server 4 project template.
In IdentityServer, the access tokens are generated to authenticate users. The Access tokens have very small limited lifetime as per convention. There's a concept of refresh token which has longer lifetime and the same is used with basic auth to get new access token. This prevents the hassle to sign in again and again.
The refresh tokens are built using a hash and are persisted in a table (if configured).
JWE is a very different setup altogether. I had my users logged out even after a new deployment of IdentityServer4 (using of persistent grants is helping to solve this).
I don't think it's not technically possible to transfer sessions from one environment to another. Both use a encryption decryption strategies which are very different from each other.
You can give a try by writing a custom implementation of TokenCreationService
I am making a REST server which will have both the web clients in form of Single Page application and in form of native mobile applications. I was studying about using JWTs to make server stateless.
Till now what I understood is :
The authentication Endpoint returns two tokens , i.e., access and refresh token after providing the correct credentials.
These Tokens should be stored in a 'httpOnly' cookie on a browser for security reasons.
As far as I know Native Mobile applications don't have cookies store and hence they have some other datastore for an application such as database. So, do I need to implement two different endpoints for these different applications? What I am thinking to do is:
Endpoint 1 (For Single Point Application): Accepts user credentials in json and Returns jwt inside cookies
Endpoint 2 (For native mobile applications) : Accepts user credentials in json and Returns jwt in raw json body.
Is the above approach right or do we have a single endpoint for both of them. Also do help how to achieve this with django-rest-framework-simplejwt.
You shouldn't need to create two different authentication views for SPAs and mobile apps. On mobile, you'll just need to store both the refresh and access tokens on the device somehow whether it's in memory or on disk or whatever. But you'll get the tokens from the same view either way. And then you'll need to include them in the Authorization header with any requests to your API that require authorization as described in the docs here: https://github.com/davesque/django-rest-framework-simplejwt#usage
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 would like to build my own REST app.
I'm planning to use oAuth as a main auth approach.
The question is: Can I use login and password as client_id and client_secret (in terms oAuth spec) ?
I don't have any third side applications, companies, sites etc... which will authenteficate my users.
I have my own REST server and JS-application.
Whole site will be made in usual(RPC) approach, but some private part will be done as RESTfull service, with enough stand-alone JS application.
UPDATED: I'm not sure that I even need full oAuth support. It seems to me that I can ask login and password on https page and then generate some token. Later i could use it to check is this user authenticated already or not. But in this case this oAuth become almost the same what we have in web aplications. I do not need oAuth to athorize users ?
I'm not consider HTTP(s) authotization because i don't want to send evrytime user and password to server.
No.
One if the main reasons OAuth exists is to allow integrations without users compromising their usernames and passwords.
If you plan on using username and password, look into xAuth as an option if you still want to sign your requests. More info: https://dev.twitter.com/docs/oauth/xauth.
But you could likely just as well go for HTTP Basic Authentication. At least if you publish your API over SSL. More info: http://en.wikipedia.org/w/index.php?title=Basic_access_authentication
I think you might get a better answer on the security site. See, for example, this question.
In any case, you need to start with a detailed assessment of what attacks you are trying to prevent and what attacks are "acceptable.". For example, if you are using HTTPS then you can probably accept the remaining danger of a man-in-the-middle attack, because it would require forging an SSL certificate. It is harder to say in general if a replay attack is acceptable.
One reasonable solution would be to create a time-limited temporary token by having the user authenticate over HTTPS with the username and password, generating a secure token with an expiration date, and then sending that token and expiration date back to the client. For example, you can create a (reasonably) secure token by taking the SHA1 hash of a secret plus the user name plus the expiration timestamp. Then the client can include the token, the user name, and the authentication timestamp in future requests and you can validate it using your secret and your clock. These need not be sent as 3 parameters; they can be concatenated into one string user|timestamp|token.
Register your application with SLI. SLI grants a unique client ID and a client secret that enables your application to authenticate to the SLI API. You must also register the redirect URI of your application for use in authentication and authorization flows.
Enable your application with specific education organizations so that the application can be approved for use in those districts.
Configure and implement the appropriate OAuth 2.0 authentication and authorization flow in your application, which includes managing sessions and authorization timeouts.