I want to use the combination of Application's Client ID + Client Secret for API Authentication instead of an OAuth Token.
Is it possible to do this with API Manager 4.x?
Yes, that is the recommended way of getting an access token. You have to use the client id and secret, then generate and access token using those.
This is a general practice and all the API Manager versions do support this capability.
Update:
You cannot just use client id and secret for authentication. The API Gateway is unable to authenticate the request with those credentials. Instead of client id and secret you can use an API key which has an infinite expiry time.
Alternatively, you can write a custom handler to achieve this use case.
Related
We are working on switching to Cognito as the 3rd party OAuth 2.0 provider for our backend services.
Our legacy system had its own Spring Authorization Server (deprecated) for generating and verifying access tokens which enabled us to add custom claims to Access Token itself, there was no need to carry around Id Token to extract information about the authorised user.
But Cognito pushes us to use OAuth 2.0 standards naturally, and there is no possibility to add custom claims to Access Tokens. Id Tokens are used for extracting custom claims and user information throughout an authorised session.
This brings us to a situation where we need to have Id tokens in the backend service sessions for the endpoints that needs some user info in order to process requests. But to fetch the Id token from the Cognito provided /userInfo endpoint, Access Tokens need to have openid scope, but to have the openid scope in the Access token, we need to use Cognito Hosted UI which is not applicable for the mobile app and our legacy Web app.
So either we need to use Identity Token as the Bearer token(not advised by standards), or we need to expect ID token with a custom HTTP header along with the Access token. Is there a huge security risk if ID tokens are used also for enabling access to REST API's ?
I'm trying to develop an OAuth solution for an AWS API using C# lambda functions.
I'm able to get a session token using the access key and secret key of a user I set up with invoke permissions for the API Gateway and functions thereon. I even have an endpoint that takes the client_id and client_secret and grant_type (client_credentials) as is standard for OAuth2.
I was then going to use the session token ONLY, which expires, to access the API endpoints.
However, when I try to find a way to validate the session token, all I can seem to find are solutions that use the access key, the secret key AND the temporary session token. I just want to use the temporary session token as a bearer token in the header under Authorization, as is standard for OAuth2.
Authorization: Bearer <session_token>
Is there any way to accomplish this or have I gone so far down a rabbit hole that there's nothing left to do but start over???
I have an API that is exposed through WSO2 API Manager, it is secured by OAuth2 so client must pass an apikey, token or credentials in order to get access to resources. So far so good. But now, I'd like to protect backend's endpoint as well. Backend only accepts calls from API Manager (IP security) but it is open, I mean, if someone with access to APIM's host does the call, it will accept since there is no authentication between them.
I would like to use Identity Server to protect backend but according to APIM documentation, supported endpoint security are BASIC or DIGEST.
What is the best approach to implement BASIC/Digest auth in SpringBoot backend and use WSO2 Identity Server as user registry? This way I can centralize every security details to a single solution.
Thanks in advance.
If you use basic auth or any such, your back end might have to do another API call to WSO2 to validate that token. Instead, you can pass a self contained JWT token from the API manager to the backend. So that the back end can validate that the JWT is issued by the API manager it self using using the certificate without relying on anything else.
From this way you can verify if the call was made y API Manager, additionally the end user as well from the JWT content.
Doc : https://apim.docs.wso2.com/en/latest/learn/api-gateway/passing-end-user-attributes-to-the-backend/passing-enduser-attributes-to-the-backend-using-jwt/?fbclid=IwAR1JT9DLOclmA-xw0Ev9C2Xrje5EDGrDBnmMkfDKMcbxTlCLf0swSPucMfA
I have an API Gateway/lambda REST API that is being accessed from a react web app. I need to add authentication using google as an identity provider. The app should also keep the user signed in.
I understand when the user first grants access to the (react) client app, it should send the ID token to my backend, which should then verify the token.
Since my architecture is serverless, I assume the verifying should be done in the API Gateway authorizer function, which then grants access to the API on successful verification of the token.
My question is, how do I then create a persistent session? Should I be saving anything to my database about the user? Does the token need to be verified on every API call?
Should the authorizer be checking if the user is already registered or if it's a new user?
It would be easiest to use AWS Cognito for this. Configure a user pool as an authorizer for your API gateway and then configure Google as an identity provider for that user pool. This link might be helpful: https://docs.aws.amazon.com/cognito/latest/developerguide/google.html. Cognito even has a hosted UI if you want to use it for signing users in.
As for your question about persisting user sessions, they usually get persisted in local storage in the browser or in a cookie or some similar mechanism. You can also persist them on the server-side in a database like you were mentioning but that isn't really for authentication purposes.
The user session will contain an access token. The access token is short-lived, meaning you can only use them for an hour usually. After that you have to use a separate refresh token to generate a new access token. And to be extra safe the refresh token itself will expires after a few days (and you have to sign back in).
I'm building an API using the serverless framework. I'm trying to authenticate requests coming in through API Gateway by leveraging Cognito (UserPools), and giving each of my users their own authorization token for each API call they make.
Trying to test it with postman I'm not able to make a call and pass authorization. I've tried setting Authorization in the header with the App Client Secret, but I'm just getting "Unauthorized" back. Is there something I'm missing?
You should be using the token rather than the App Client Secret. How are you retrieving the token?
For user sign in authorization, you must be sure you uncheck the option to generate client secret when you are creating a new Client Application inside UserPool.
In your API Gateway you create an authorizer making a reference to you before created UserPool. Inform "authorization" for the header.
Using a AWS third party SDK service (or just their API), signin with a valid user. You will get 2 types of tokens after the login, make sure you keep the right one. I advise you to check the token through the API Gateway authorizer testing option. Note: This step is the most important, as you are isolating the token you get and the authorization service. This way you can track the source of your problem.