I have a Flask app running in AWS using Flask-JWT-Extended. It is serving REST API calls to a web app.
As I understand from the documentation, the tokens are generated and stored in memory. I am considering storing them external to the Flask app in either a database or Redis. The reason for this is to support load balancing:
I presume that sticky-sessions would be required to make sure that the client's token can be properly decoded and analyzed for validity
I am considering putting the app in AWS Lambda, which would probably wipe out the JWT list once the request was served.
My questions are:
Is there any reason this scheme would not generally work?
If the tokens are stored outside the Flask app, it is not clear how to override the local token storage and access an external storage medium. Can this be done?
The tokens are not stored in memory. JWT works by creating tokens that can be verified to have not been tampered with without having to keep any state on the server (just make sure to keep the JWT_SECRET_KEY really and truly secret). Here is an article about stateless authentication you might want to read up on: https://blog.imaginea.com/stateless-authentication-using-jwt-2/
Related
In my flask app, resources are handled with #jwt_required(). A new login creates a new JWT Token. I saved access_token in database and removed old jwt. But i can access the resources with the old jwt token. Is there any process where i can prevent using old jwt?
It is not possible to "destroy" an old token, it remains valid until the date specified during its creation. However, the Flask-JWT library offers the possibility of blocking an old jwt.
To do this you will need to use redis or a database, which will be used by Flask-JWT as an archive to store the revoked tokens
Redis:
If your only requirements are to check if a JWT has been revoked, our
recommendation is to use redis. It is blazing fast, can be configured
to persist data to disc, and can automatically clear out JWTs after
they expire by utilizing the Time To Live (TTL) functionality when
storing a JWT.
Database:
If you need to keep track of information about revoked JWTs our
recommendation is to utilize a database. This allows you to easily
store and utilize metadata for revoked tokens, such as when it was
revoked, who revoked it, can it be un-revoked, etc.
In the link I left you you can also find a complete example for both options
I am using the amazon-cognito-identity-js library in express/node backend to handle all authentication. Basically when I try to log in on my front end, it logs me in and persists the state without ever storing tokens in localstorage. Is this happening because I implemented the library in the backend, so all the session data is being stored on the server? I don't pass tokens from the backend to the frtontend. Is it a good approach? I understand this library was meant for frontend but it seems like it is working in the backend too?
I'm not sure how you have implemented this in the backend. Doesn't it just overwrite sessions as multiple users log in? This is why it was designed to be implemented on the front end. If you want your backend to handle authentication then you are passing credentials to you backend which might not be a good idea. But if you still want to go with this approach then you can write an API that accepts credentials and returns tokens. Do it without sdk and don't store any tokens. On front end you can store tokens in localstorage if you want.
I have an access token and a refresh token generated using my cf credentials. I want my app, which uses CF API, to run continuosly for a long time, so when the access token expires I will generate a new one using the refresh token. But as far as I understand a refresh token will also expire, so authorization session is limited. I could generate a new access token using my credentials but I don't want to store them neither in code files nor in environment variables. Can I do something about it?
Check out CF-Space-Security. It let's you proxy through a process that is running next to your process and manages tokens.
To make this work properly, you need a UAA Client. Rather than pass in your access/refresh tokens, you'd pass in a UAA client & secret. You would then perform a client credentials grant to obtain an access token using your UAA client & secret. This results in an access/refresh token that you can use to make requests to Cloud Controller.
You would typically send the UAA Client & Client Secret to your app via env variables or perhaps as a user provided service. You could use something else though (CredHub, Vault, etc..), if it's available in your environment.
If you're using Java, the cf-java-client will handle all this for you. Instead of creating a PasswordGrantTokenProvider in the example at the link below, you'd use ClientCredentialsGrantTokenProvider.
https://github.com/cloudfoundry/cf-java-client/tree/master#cloudfoundryclient-dopplerclient-uaaclient-builders
That said, you don't really need a special library. You can use whatever Oauth2 libraries are available in your programming language of choice, so long as it supports the client credentials grant type.
If you don't want to do this in code, #poy's answer is also good. It is enabling access by handling what I mentioned above in a proxy. So long as your requests go through the proxy they'll be annotated with an access token.
Please make sure you understand what the proxy is doing though before you deploy it & make sure you understand how to properly secure it. Anything with access to the proxy could send authorized requests, so you really need to make sure it's locked down properly.
Hope that helps!
I've been trying to learn the inner workings of OAuth 2.0 in my own RESTful app, and I can't seem to find any good explanation of how my Javascript client handles the process.
At this point, I have the client (an Angular 2 SPA) ask the user for their username and password (running Django Rest Framework along with Django Oauth Toolkit). The client makes an AJAX post to the server (specifically to /o/token), and using the resource owner password credentials flow is authenticated and receives the response with the token.
Now, assuming I'm doing everything correctly up to this point, I'm unsure how to properly handle the token from that point forward.
At this point, I'm having my Angular app save the token in a variable and attach the authorization header (with the token) to the calls made to the API. This works as far as granting the correct permissions, but im having a hard time understanding how to maintain persistence of the header (so if the user navigates to a different page, the token is still callable). Initially I stored it in a cookie, but I have concerns with security.
So, first, am I understanding all this correctly? What kind of security concerns should I take into account here? And, of course, how can I save the token on the client?
Yes, you need to store access tokens as user session data because they should be persistent. For example if user leaves your site and then reopens he expects to see himself logged in.
It will be better if you make your sessions server-side: user-agent will store only session ID and all user data will be in your database. User don't need his access token, only your application does.
Instructions for implementation of server-side sessions for Django look pretty simple:
If you want to use a database-backed session, you need to add 'django.contrib.sessions' to your INSTALLED_APPS setting.
Once you have configured your installation, run manage.py migrate to install the single database table that stores session data.
I am starting to work on an authentication system for an angular 2 Single Page Application using django-rest framework as back-end. I'd also like to have some kind of "remember me" functionality that is going to keep users logged in for a certain amount of time.
From what I have read so far, it seems that the best authentication method for this kind of Angular 2 SPA/REST API is using jwt (json web token). For jwt authentication, I looked at the django-rest-framework-jwt (https://github.com/GetBlimp/django-rest-framework-jwt).
The problem that I see is that the token needs to have a short life span (few minutes to a few hours...) in order to minimize security issues if the token get stolen. The token now needs to be refreshed frequently to avoid the user from being disconnected while using the application. In this case, a "remember me" functionality is posing problem since the token have a short life span.
I thought about a solution involving a second token that would serve as a refresh token. It would be opaque, have a longer life span and would contain information specific to the user (ip address or something like that) so that if it get stolen, the information specific to the user being different would render this refresh token invalid.
So here are my questions:
1- I would like to know if they are existing solutions addressing this problem. As any security/authentication issues, I prefer to rely on well tested solutions to avoid getting my API compromised.
2- Would the refresh token based on specific user infos be a good idea?
3- Any other ideas how I could implement what I want?
For your situation, you really need a way to store issued tokens.
I always use an OAuth2.0 server setup that manages the auth and returns tokens the OAuth setup uses a database to manage everything so it's easy to manage and revoke tokens.
The database schema would be like this http://imgur.com/a/oRbP2 the problem with using just JWT without any management over the issued tokens with long expiration you have that security issue of not being able to revoke easily.
I would advise against including any such thing as a password in the JWT and requiring them to change it what if they use that password everywhere, then they would have to change that everywhere.
Updated from comments
Sessions Authentication use session_id which most the time is stored in a cookie and this is attached to every outgoing request. It is stateful. It is nothing more than a unique identifier that associates a user account that the server has in memory/database. For example, this can course problems when running multiple servers/instances when scaling your infrastructure.
Token Authentication no session is persisted on the server so this means it is stateless. It normally uses the header Authorization: Bearer REPLACE-WITH-TOKEN . This means that this token can be passed to multiple different servers/instances because the authentication is not limited to the server that you initiated the authentication on. This helps with scaling your infrastructure. Tokens can also be passed to other clients.
RESTful API's are stateless so there must not be a session state stored on the server. Instead, it must the handled entirely by the client so that's why token authentication is used.
I had the exact problem when trying to use JWT with an application that needed a lot more than JWT was designed for. OAuth2.0 has a lot more options that I believe are necessary to meet your requirement in the safest manner possible and even features that you may find very useful in the future as your Application may grow and need more features with regards authentication.