I am working on creating an api using aws api gateway service. Api gateway is backed by a lambda function written in python.
My Api gateway would be secure and I am using cognito authentication/authorization where consumers would first retrieve oauth token and pass that as Authorization header
I am planning to extend use of scope and planning to map this to my backend service to further narrow down access to underlying resources, if I can extract scope programatically
ex:
if scope is myscope/tx - only get all transactions to consumer etc
My Question is that how do I retrieve this scope from oauth token ? I googled and found similar question for java , but unfortunately this was not helpful in my case, here is that url How to retrieve scopes from OAuth token within Spring boot SSO + zuul
I am also aware of using https://jwt.io/ to find this manually but in my case I am looking for a programmatic solution in python
It would be great if someone have ever done this ?
-Thanks
I googled and found similar question for java , but unfortunately this was not helpful in my case, here is that url How to retrieve scopes from OAuth token within Spring boot SSO + zuul
I am also aware of using https://jwt.io/ to find this manually but in my case I am looking for a programmatic solution in python
I am expecting solution in python
Related
I don't know why I can't find confirmation in the docs, maybe I am not navigating them correctly, although MSAL seems to have options to fit it into any application. This is my first time integrating a SAML sso procedure into any of my web-apps. I am just looking for some clarity on the correct, and secure way to verify the person attempting to login, is actually logged in with the IDP.
I am confused at the part after confirmation of login is given to my redirect API, I currently have it all happening on the front-end, then submitting the response to my back-end. Which is a RESTful API built with Django, and postgres database. At this point, I am thinking I need to verify my accessToken for authenticity, but I am unsure if I should be creating another PublicClient instance in python, and then sending the same commands to the IDP.
To guess at this point, I'm thinking this is wrong, as I need to verify the token, rather than get another Access and Refresh token. I'm thinking I just need to verify there is a session open with the IDP, and that the Access Token matches. Can anyone shed some light on this, possibly provide even just some direction.
The client Python Django Web App uses the Microsoft Authentication Library (MSAL) to sign-in and obtain an Access Token from Azure AD.
The access token is used as a bearer token to authorize the user to call the Python Flask Web API protected by Azure AD.
The Python Flask Web API then receives a token for Azure Resource Management API using the On-Behalf-Of flow.
To learn more about handing access token validation at the API layer, look into this sample walkthrough: https://github.com/Azure-Samples/ms-identity-python-on-behalf-of#about-the-code
https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens#validating-tokens
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.
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
I have a python microservice which I would love to connect to AWS API Gateway. - The problem is that I have researched ways to make both secure, but not really came to a conclusion.
I came across a site saying I should use SSL Certifications to only enable requests from API Gateway.
Can someone enlighten me on what's the best practice for authentication between the client and API Gateway and the API itself?
There are a very large number of ways to authenticate between the client and API Gateway. There is no "best" way.
To authenticate between API gateway and the back-end servers, you would use SSL authentication as described here: http://docs.aws.amazon.com/apigateway/latest/developerguide/getting-started-client-side-ssl-authentication.html
There are couple of approaches to implement authentication in API gateway. Different approach serves different purposes and level of security you expects to achieve.
For most of the cases you can write your custom authorizer lambda for authentication. With help of JWT you can create a reasonably secure Authentication for your API. If you use IAM authentication API Gateway directly supports it. Only limitation is you need to use AWS SDK to invoke the API for convenience. Since API gateway uses SSL by default, data transfer is already encrypted.
If you have very specific security requirements then you can use SSL certificates. This is generally preferred when communicating between API's in Service Orchestration like scenarios in SOA.
You ask what the "best practice" is, and, since we are in Amazon's AWS ecosystem, that's surely to use AWS Cognito.
If you go this route, you will have vendor lockin for your authentication flow, but it works very well as they are built to play nicely together. Logins occur via calls to AWS Cognito endpoints: successful ones will receive session tokens which can then be used in future for any API Gateway calls.
To enable, just click into any API Gateway Method, click into Method Request, edit Authorization, and you will see your AWS Cognito User Pools you have created.
This takes a bit of configuration, but it works very well.
I am pretty new to developing APIs. This is part of my class project and the goal is to create a RESTful API in python where the delegation is done via OAuth and these tokens should be sent as part of the HTTP request.
I was advised that I should create an API that involves delegating the OAuth model into a proxy-like approach where authentication tokens are sent as part of the HTTP request. What exactly does a proxy-like approach mean? Any ideas?
I would really appreciate if anyone could help me out with this and also on how to create an API (even if it is not python specific, I can take cue from that)
If you are new to REST services, then this link will be nice kick start for you.
You can find here how to develop a basic rest api in python and the same with authentication.
So what is OAuth?
OAuth can be many things. It is most commonly used to allow an application (the consumer) to access data or services that the user (the resource owner) has with another service (the provider), and this is done in a way that prevents the consumer from knowing the login credentials that the user has with the provider.
For example, consider a website or application that asks you for permission to access your Facebook account and post something to your timeline. In this example you are the resource holder (you own your Facebook timeline), the third party application is the consumer and Facebook is the provider. Even if you grant access and the consumer application writes to your timeline, it never sees your Facebook login information.
This usage of OAuth does not apply to a client/server RESTful API. Something like this would only make sense if your RESTful API can be accessed by third party applications (consumers).
In the case of a direct client/server communication there is no need to hide login credentials, the client (curl in the examples above) receives the credentials from the user and uses them to authenticate requests with the server directly.