I have a resource server (built with Flask, but not sure if that matters right now) that has a RESTful API. The API is secured with OAuth2 access tokens and scopes.
Currently the access tokens are opaque (not JWT) and the resource server needs to call the /oauth/token/info endpoint on the auth server to check if the access token is valid and get the list of scopes associated with the access token, and then validate the scopes granted against the ones required. We have some custom code for this.
We now want to start to use JWT access tokens so that we can avoid this call to the auth server, but we can't roll them out to all OAuth clients just yet, only some. So the resource server will be getting a mix of opaque access tokens and JWT access tokens. The JWT will be signed with a RS256 private/public key, and the public key will be available from the auth server at a /oauth/discovery/keys endpoint that the resource servers could hit on startup once and cache so that it doesn't need to hit it on every request, unless the public key changes and doesn't match the kid in the JWT.
While doing this, I was hoping we could get rid of some of the custom code we've written and use some tried and tested library for us, hence AuthLib.
However, I can't seem to find any good examples of how to configure a resource server to handle either of these cases individually, let alone both at the same time. The examples I see seem to assume the resource server has access to the access token database.
I'm assuming I will need to write my own BearerTokenValidator that handles this, but I was hoping there would be examples somewhere on how to go about that. Ideally with the ability to cache the public key for the JWT and only refresh when the JWT kid claim changes.
I was sort of hoping that a TokenInfoBearerTokenValidator and a JWTBearerTokenValidator existed that I could use that did most of the work for me. Maybe there are and I'm just missing it?
AuthLib 1.0 has been released with additional support fro JWTBearerTokens that makes this easier to accomplish now.
Related
I'm writing an application (web and mobile) where I would like to use WSO2 for user authentication, authorization and SSO.
My mobile app will authenticate the users against the WSO2-is.
All the API's used by the app are google cloud functions written in python.
I would like to bring a security layer to my GCF's.
From my understanding I can use WSO2-am as a bridge between the app and the GCF to provide security, but I would like to leverage the high scalability of the GCF archicteture and avoid the WSO2-am being a bottleneck.
Is it possible use the WSO2-am and make the GCF to check the permissions access against it, allowing the app calling the API directly instead of using the WSO2-am as a bridge ?
If yes, may you provide some documentation/blogpost/whatever that could help ?
In WSO2 APIM, the gateway does all the authentication and authorization stuff when the requests go through it (to the backend).
So, in the case of,
(1) OAuth2 tokens, the gateway talks to the key manager to validate the token, subscription (API-to-Application) and token scopes.
(2) Self-contained JWT tokens, the gateway can do all these validations itself.
So now in your case, since you don't want to send the requests through the gateway, you have to do what gateway does, within the cloud function itself. In that case, the JWT tokens will be the best choice as they can be validated without connecting to the key manager.
In addition to that, the gateway keeps a token cache so that it doesn't have to validate the same token again and again. You can have a similar cache (if possible) within your cloud functions too. However, in your case, you will have to externalize the cache due to the short-lifetime nature of cloud functions.
Here is the gateway code[1] which does the token, scopes and subscription validations. You can use it as a guide to write yours.
[1] https://github.com/wso2/carbon-apimgt/blob/master/components/apimgt/org.wso2.carbon.apimgt.gateway/src/main/java/org/wso2/carbon/apimgt/gateway/handlers/security/jwt/JWTValidator.java
There's a lot out there on how to issue JWT tokens to clients from Django, but I'm looking for a way to store a JWT token that is issued to the Django app for authentication against an external API.
The setup:
Django requests and receives token from external API. It is good for 24 hours.
Every time a client a makes a request, the app must make an authenticated call to the external API. Ideally, if 3 clients make 2 requests each, we should only need to request a single JWT.
24 hours later, a fourth client makes a request. Django sees that the token is invalid and requests a new one.
The problems here:
Requests from multiple clients should not each require their own token.
The token must be able to be changed (this rules out sticking it in the settings)
The token must be stored securely.
Ideas so far:
Stick in the database with a field listing the expiry time. This seems questionable from a security standpoint.
Implement some kind of in memory storage like this https://github.com/waveaccounting/dj-inmemorystorage . This seems like overkill.
Any suggestions as to a better way to do this?
The django cache was the way to go. See the above link for an example.
I have a python application that needs to give users a JSON web token for authentication. The token is built using the PyJWT library (import jwt).
From what I have been reading it seems like an acceptable practice to give the token to a client after they have provided some credentials, such as logging in.
The client then uses that token in the HTTP request header in the Authorization Bearer field which must happen over TLS to ensure the token is not exposed.
The part I do not understand is what if the client exposes that token accidentally? Won't that enable anybody with that token to impersonate them?
What is the most secure way to hand off the token to a client?
You could encrypt the token before handing it off to the client, either using their own public key, or delivering them the key out of band. That secures the delivery, but still does not cover everything.
In short, there's no easy solution. You can perform due diligence and require use of security features, but once the client has decrypted the token, there is still no way to ensure they won't accidentally or otherwise expose it anyway. Good security requires both participants practice good habits.
The nice thing about tokens is you can just give them a preset lifespan, or easily revoke them and generate new ones if you suspect they have been compromised.
Token will be build based on user provided information and what you back-end decided to be part of the token. For higher security you can just widen your token information to some specific data of the user like current ip address or device mac address, this will give you a more secure way of authentication but will restrict user to every time use the same device, as a matter you can send a confirmation email when a new login happens.
I am writing a basic python script and I am trying to use the Github API. Because I am new to the development scene, I am unsure of what I can share with other developers. Do I generate a new personal access token (that I assume can be revoked) or do I give them Client ID and Client Secret?
Can someone explain how OAuth (Client ID and Client Secret) is different from a personal access keys?
Does this logic work across all APIs (not just on Github's)?
The Short, Simple Answer
You should probably give them none of those things. They are equivalent to handing over your username and password to someone.
The Longer Answer
It depends...
Personal Access Tokens
Your personal access token is a unique token that authorises and represents you during API calls, the same way that logging via the web interface authorises you to perform actions there. So when you call an API function with a personal access token, you are performing that API action as if you yourself had logged in and performed the same action. Therefore, if you were to give someone else your token, they would have the same access to the site as they would have if you gave them you username and password combination.
Personal access tokens have attached scopes. Scopes control exactly how much access to GitHub a particular token has. For example, one token my have access to all private repositories, but another token only to public ones.
Client IDs
A client ID represents your application, rather than you. So when you create an application, GitHub gives you an ID that you use to identify your application to GitHub.
Chiefly this allows someone logging into your application using OAuth to see on the GitHub web interface that it's your particular application requesting access to their account.
Client Secrets
A client secret is a random, unguessable string that is used to provide an extra layer of authentication between your application and GitHub. If you think of the client ID as the username of your application, you can think of the client secret as the password.
Should I Share Them?
Whether you wish to share any of these things depends largely on how much you trust the other developers. If you are all working on the same application, it's likely that you will all know the client ID and client secret. But if you want to develop an open-source application that people will install on their own machines, they should generate their own client ID and secrets for their own instances of the app.
It's unlikely that you should ever share a personal access token, but if you have a bot account used by the whole team, then sharing the tokens could also be okay.
I'm going to build an API in Flask for a (to be created) app which will be built using PhoneGap. In the API many calls will need authentication.
To get into the topic I was reading this tutorial on creating authentication for a Flask-built API. In this tutorial they first show how a user can use basic password authentication for every call, after which token based authentication is introduced.
As far as I understand, the client who calls the API should simply get a token and authenticate every subsequent call with that. In the meantime, the client should keep track of time and either get a new token every 9 minutes (before the old token expires) or simply keep on calling with the token until the client gets an Unauhorized Access message. Am I understanding this correctly?
Moving on, I wonder how it works with Apps on which you login on your phone and then are always logged in whenever you open the app (like for example the Facebook app). This is obviously more convenient to the user than always needing to provide the username/password and I would like to implement something like that as well. I wonder though; how is a permanent logged in feature like this implemented on the server side? Is it done by providing the password and username for every call, or using a never expiring token, or yet a different way?
All tips are welcome!
I've done what you want to do with:
Flask-security https://pythonhosted.org/Flask-Security/:
To manage users and permissions.
Flask-oauth-lib https://flask-oauthlib.readthedocs.org/en/latest/:
Provide oauth functionnality.
So, you have to take a look at Oauth flow, implements a user backend (like Flask-security) and implements an oauth server (with flask oauth lib for example) and bind it to your user backend.
After that, it's oauth standard flow. You just have to give the right token on each api calls and TADA !
With this way you can also, if you want, give access to your api to third-party app thanks to oAuth :)