Cannot use token in WSO2 APIM with custom certificate - wso2

I a trying to deploy WSO2 API manager (APIM) with a custom valid certificate and to use the option to encrypt in the DB token and secret user information.
I can use my certificate all right, its green even in chrome and everything will work: token emission, api consomption with a token and token revocation. But, as soon as I try to use the option to encrypt tokens I get an error when trying to use the token. Token expired. If I push the logging to DEBUG level, nothing unusual happens but for the token being considered expired and APIM returns expired credentials.
Any one know how to use this options ? And yes, I have tried to set that option from the get go to make sure is active before any user, api, tenant or anything else is created on the server. If I deactivate it, every thing works normally for subscription taken after deactivation.
Thank you.

Related

How to create OAuth2 Opaque(Reference) Access Tokens

How to create OAuth2 Opaque(Reference) Access Tokens in apimanager 410? I followed enter link description here, but cannot find OAUTH token type when we create applications.
I want to create this application because of the issue enter link description here. if same token is sent every time we call the token api, this will work for us. Our tests need to get the token first and use it from there. there can be different apis calling in different times and this will expire the first token.
There is a lengthy manual method that lets you to create opaque tokens in APIM 4.1.0, but our recommendation is to proceed with the JWT token-based applications. This will reduce the load at the gateway with token validation which is a huge performance gain. Even if you used the same clientID, or secret Pair, you can change the scopes set with a device scope and I believe this should give you the ability to create multiple tokens at the same time.
Having said that, you can create opaque token in the below approach, but this will remove the user experience provided in the devportal and you have to use carbon console(https://localhost:9443/carbon) if you need to change your application.
log in to admin portal (https://localhost:9443/admin)
Open Key managers --> resident key manager (or whatever the key manager you have) --> and select Out Of Band Provisioning and save.
Log in to carbon console (https://localhost:9443/carabon)
Register a service provider.
Under Inbound authentication config, select OAuth/OpenID connect configurations and configure an OAuth Applicaiton
Add you application details from here as you prefer with the listed grant types and create an application.
Make sure to select the token issuer and default. This is where you select whether the token type is JWT or Opaque.
Once you save it, you can find the client ID secret pair in here.
Log in to devportal (https://localhost:9443/devportal)
Create an application.
Under the production Keys section, now you can see a new option enabled as provide existing OAuth keys.
Add the consumer key secret pair you created in the step 8.
Now you have created an application that generates opaque tokens.
In the latest API Manager versions do not allow generating opaque access tokens. You can use the following configuration to the deployment.toml of API Manager and disable token revocation on token renewal.
[oauth.access_token]
invoke_token_revocation_event_on_renewal = false

how can I Separate Refresh token with Get access token?

I created "test-App" application in API Manager WSO2 with the grant types of "refresh-token" "SAML2", "PASSWORD" "Client Credentials" and "JWT"
I also Created a "test"
To use the webservices behind API manager, First, I should call https://localhost:9443/oauth2/token) to get a access-token
Unfortunately, if I call the link again, instead of receiving the same access-token, the system will generate a new access-token and the previous access-token would be expired. ( I think this link is more like refresh token rather than get the access token).
So, How can I Separate getting available access-token and Refresh-token link in WSO2 API Manager ?
In the latest versions of API Manager you have JWT tokens. When you request a new token it always generates a new token. But it doesn’t revoke the previous access token.
In the earlier versions of APIM, opaque tokens were supported and it has a different behavior. When you request a token, if it is not expired you get the same token.
Please read more about refresh grant here https://apim.docs.wso2.com/en/latest/design/api-security/oauth2/grant-types/refresh-token-grant/
If you have not done any other configuration changes, invoking https://localhost:9443/oauth2/token URL will always generate a new JWT token without expiring the earlier one. However, the token validity can be changed in the Dev Portal while generating the access token.

WSO2 Federated IDP RefreshToken with invalid username

community.
I'm using WSO2 IS 5.7.0 to integrate an Angular app with an external IDP.
The external IDP is configured with SAML2 and the service provider Inbound Authentication is set with Oauth/OpenID.
The service provider uses Federated Authentication to comunicate with the IDP.
The user uid from the IDP is matched with the claim userid, so when I ask for an oauth token, I get the correct scopes (matching a local user with roles configured) to use the token with WSO2 AM. This is working well whe I get the initial oauth token using code grant.
If I introspect this token, I can verify the token belongs to the username XXXXXXXX and the scopes are the ones to consume an API on WSO2 AM, based on the roles associated to the local user XXXXXXXX.
The problem is when the refresh token is used to get a new access token after expiration. The new access token comes with the same scopes, but I cannot consume the same API I was consuming with the first token. I get a 403 Forbidden on every call and the AM log shows:
WARN - APIAuthenticationHandler API authentication failure due to Invalid Credentials
(The first WARN appears only once)
WARN - APIAuthenticationHandler API authentication failure due to The access token does not allow you to access the requested resource
(this WARN appears on the subsequent calls)
If I introspect the receibed token, I can see the same scopes as the original access token, but the username is different:
FEDERATED/XXXXXXXX#carbon.super.
I think this username change on the token information leads to the 403 error.
The problem is worst if I activate the Service Provider option "Use tenant domain in local subject identifier" on the Local & Outbound Authentication Configuration. In this case, every time I ask for a new token with refresh token, the tenant is appended to the username on an infinite loop:
XXXXXXXX#carbon.super#carbon.super#carbon.super#carbon.super
On every token I get, the introspect shows me another #carbon.super is appended to the username of the actual token. In this case, the FEDERATED/ is not always present on the username.
I expect the username associated to the refreshtoken to be equal to the one on the first access token.
Is there a configuration to solve this or this is a bug? is resolved on new releases of WSO2 IS?
(sorry for my english)
Thanks!
Similar issue is reported[1] and fixed with PR[2].
[1] https://github.com/wso2/product-is/issues/4472
[2] https://github.com/wso2-extensions/identity-inbound-auth-oauth/pull/1022
If you don't have a WSO2 subscription, upgrading to the 5.8.0 will resolve the issue.

Is there a way to get UAA access token from the app without storing credentials?

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!

"Access token does not contain openid scope" in AWS Cognito

I am running a working AWS Cognito service on a frontend application which can successfully do the basic stuff - login, logout, signup, etc..
Right now I am trying to get user attributes through the backend API, such that:
1) The user login in the application and gets a JWT.
2) The JWT is being sent to the backend server.
3) The server has to extract the email of the user by using the access token
The closest thing that I found to what I need is this Cognito service.
So I am making a GET request to "https://mydomain.auth.eu-central-1.amazoncognito.com/oauth2/userInfo"
With Authorization Header as they are asking for, but I keep getting this response:
{
"error": "invalid_token",
"error_description": "Access token does not contain openid scope"
}
I have tried searching for this error but couldn't find any explanation about the error.
Thanks by advance
Erez, are you using a custom UI?
Because the custom UI uses flows that are completely separated from the OAuth2 ones (USER_SRP_AUTH, USER_PASSWORD_AUTH). Tokens that are released with these flows are not OpenID Connect compliant (basically they don't contain the openid scope) so you cannot use them to gather user infos (since the userinfo endpoint is OpenID Connect compliant and needs to be invoked with jwts compliant with OIDC standard).
We're also struggling on that, i'm sorry.
I had this exact problem and it was my fault. I was sending the id_token instead of access_token property of the token.
I program in PHP, so I was sending as header "Authorization: Bearer ".$token->id_token instead of "Authorization: Bearer ".$token->access_token. Now it works.
Hope it helps you or someone.
I am still experiencing the same issue. My problem relies on programmatic use of signIn service (not Hosted UI via federated login) in Amplify framework. After a long googling, I have discovered that this is because "openid" is not including in the scope of token. Only "aws.cognito.signin.user.admin" is included.
You can find a reference here, thread is still open https://github.com/aws-amplify/amplify-js/issues/3732
This solution seems to be fine for me How to verify JWT from AWS Cognito in the API backend?
If I understand correctly, you are successfully getting the #id_token sent to your front end from Cognito (steps 1-3). You can enable scopes on the #id_token by selecting the following options in your Cognito Pool App Client Settings:
I had a similar issue and I spent a couple of hours to find a solution. The access token you received it from cognito in your frontend application you need to send it to your backend then decode it and verify it. here is a good documentation from aws: https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html