I'm setting up OIDC provider for Cognito User pool. The open id connect service I'm using is Paypal. At the step where paypal issues code and redirects to cognito's /oauth2/idpresponse endpoint after which cognito is supposed to exchange the code for access token, I'm receiving "Exception processing authorization code" error. As you can see the error message is not very discriptive.
I have no idea what I'm doing wrong. I did setup open id connect properly. Setup client settings in cognito and etc.
These are the endpoints I'm using for openid connect:
https://www.sandbox.paypal.com/signin/authorize
https://api.sandbox.paypal.com/v1/identity/openidconnect/tokenservice
https://api.sandbox.paypal.com/v1/oauth2/token/userinfo
https://api.sandbox.paypal.com/v1/oauth2/certs
In app client settings I have auth code grant flow and implicit flow enabled. I have custom domain setup. I provided paypal client id and secret
My guess is if I'm able to somehow debug idpresponse endpoint I should be able to solve the problem. Is there any way to do that? Maybe cloudwatch?
I don't know about debugging Cognito's endpoints, but I had the same problem and fixed it by doing the following:
Go to your User Pool in AWS.
In the side navigation under Federation, select Attribute mapping.
Click the tab of the identity provider you're having issues with (in my case it was Google).
There should be three columns, Capture, Google attribute, and User pool attribute. Make sure all of the attributes that are checked in the Capture column are mapped to an attribute in the User pool attribute column.
UPDATE:
After submitting this answer, I realized that the checkboxes in the Capture column are not checked by default. If you marked any attributes as required in the Attributes section of your user pool, then you need to map those attributes to the attributes provided by your external identity providers.
For example, I marked email as a required attribute in my user pool settings. So, when I added Google as an identity provider, I had to go to Federation->Attribute mapping, click on the tab for Google, check the box in the Capture column next to email, and select Email from the dropdown box in the User pool attribute column.
After taking these steps, the sign in work-flow worked for me.
My guess is the auth flow works just fine between Cognito and your identity provider, but Cognito doesn't know how to map the attributes returned from the identity provider to the attributes you have set in your user pool (in General settings->Attributes under the Which standard attributes are required section).
Related
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
I have some applications served to my company users on EKS (i.e., Jenkins). In company we use Google Workspaces (GSuite) for email and stuff. So I want to allow users to login with Google creds to those applications I serve. I figured out I could use Cognito to achieve it but I cannot connect those and flow end with Google showing 403. Error: app_not_configured_for_user. In their documentation I can find:
Verify that the value in the saml:Issuer tag in the SAMLRequest matches the Entity ID value configured in the SAML Service Provider Details section in the Admin console. This value is case-sensitive.
but how do I debug it? I do not see a logs from neither AWS and Google sides :/
I think I followed all possible guides and I cannot find what I'm doing wrong. I found that Google has this page but they do not provide exact scenario for AWS Cognito. Anyways all of those are very similar so I guess I shouldn't have problems, but I do have.
What I did:
In Google Admin (one for workspaces) I created "Web and mobile app" of SAML type
I downloaded metadata file
In AWS Cognito console I created User Pool
I created IdP provider and uploaded metadata file there
I created application client
Using those values I filled fields ACS URL and Entity ID in Google Admin using values:
ACS URL: https://my-domain-i-just-created.auth.us-east-1.amazoncognito.com/saml2/idpresponse
Entity ID: urn:amazon:cognito:sp:us-east-1_myPoolId
I also selected Name ID format to be Persisted
In attribute mapping I mapped email value to http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress.
In AWS Cognito I enabled HostedUI and also created mapping of http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress to email field.
And now when I click View Hosted UI in AWS console it will redirect me to Google authentication and after it directly to before mentioned 403 app_not_configured_for_user page.
I tied it 3 times with slightly different configurations of mapping, signed responses, etc. but nothing gets me past that error.
Anyone tried to integrate it?
How to troubleshoot the 403 app_not_configured_for_user error related to SAML apps from the Google Workspace Admin console
The first thing you need to do is to grab a HAR file recording the whole login process and find the SAML request. Steps can be found here.
Once you get the file you can open it using that tool and search for SAMLreq at the top right (see image).
After that you will get a list of values containing information. You will have to check one by one until you find the one that has the SAML request in the request tab (see example below).
Once you get the value from the SAML request, copy it and you can use this tool to do a SAML decode and find the entity ID. You can use Ctrl + F and search for saml:Issuer to find the value faster. If the value does not match, then you know you have an error and you will need to contact the support team from the app to see which value is the correct one.
In case the value matches I would recommend opening a ticket to check with Google.
I would like to use a Cognito User Pool for Facebook logins only, which may be possible using the built in login form, but I need to use my own.
Theoretically, when it comes to a custom form, it shouldn't be hard: after I receive a user object from FB, I bind the user and email attributes to the ones in my User Pool and I save it.
But what to do about the password field and future authentication? And here I have failed during my journey...
...
userPool.signUp('FoobarUser', '**password?**', attributeList, null, function(err, result){
...
While digging deeper into the docs, I tried to implement a Identity Pool (Federated Identities), managed to save user info in the form of datasets as well, but then I realised, querying these sets gonna be a huge pain if possible at all.
Maybe I'm failing to understand the concepts, I would be really thankful if someone could suggest a way to manage facebook logins in a nicely organised fashion using Cognito.
So here is what I understand from your query.
Setup
Link Facebook to userpool
The app client allows only Facebook login, no other providers allowed (not even Userpool)
On login, you want Facebook user's info to be automatically populated in your Userpool
You don't want to use Cognito's builtin UI but use your own
My 2 Cents
In your app client, just select Facebook
In your UI, have a login button. On clicking it should redirect to your userpool's authorization endpoint
https://your_domain.auth.us-east-1.amazoncognito.com/oauth2/authorize?redirect_uri=https://www.example.com&response_type=token&client_id=your_appclient_id
If you want to use your own UI with multiple providers, allow the same in Client and on clicking the appropriate button in your UI (say Facebook), redirect users to the authorize endpoint but append the identity_provider in the URL
https://your_domain.auth.us-east-1.amazoncognito.com/oauth2/authorize?redirect_uri=https://www.example.com&response_type=token&client_id=your_appclient_id&identity_provider=Facebook
If you want to see the names of all supported identity providers, use ListIdentityProviders API call
This way, all Facebook users will be automatically created in your userpool. Of course, their names will be random like Facebook_123jkjdwj but all their details will be correctly populated from the token as per your attribute mapping. As a plus, all auto-created users from a particular provider are added to an auto-created group 'Userpoolid_providername' eg. us_east_1_xxxx_Facebook.
Once the cognito-id is created for a user logging via. google, how to find the email id of the user.
As shown in the above picture, I can find the cognito-id, but couldn't find any other information that google could have supplied when the user logged in.
Any help is appreciated.
Thanks in advance,
First make sure you provide email in scopes. Usually the scope is defined as profile email openid.
Next you have to "Configure attribute mapping" which is on the bottom right of the "Identity providers" section. There you can map Google's email attribute to the Email attribute of the user pool.
You'd probably have to remove users from the pool that logged in prior to the additional configuration to properly fetch the attributes. You can do this by clicking on the google user in the user pool then click "Disable" then "Delete". For example, I couldn't see the picture attribute of a google user until I removed my user from the pool and logged in again.
You should now be able to see the email attribute (and other properly configured) when you click on the user. You should also be able to see these attributes when you decode the id_token and when you call the <AUTH_DOMAIN>/oauth2/userInfo endpoint.
Cognito leverages these tokens to sign in users, but doesn't store any additional metadata against the user. It doesn't track any of it, so you won't see it there. To do so, you'd need to grab it from Google during sign in, and either store it in Cognito sync or in an external datastore (e.g. a dynamo table keyed by identity id).
I have this problem when using SAML SSO authentication. I have successfully set up WSO2IS 5.0.0 Identity server, I also succeeded setting up (at least I hope so) secondary user store. I used JDBCUserStoreManager implementation. I have set this store as DOMAIN. This user store works nice, at least I think it does. Because it is storing user attributes into its tables (USER_ATTRIBUTES) and those attributes are read by WSO2IS administration ...
https://localhost:9443/carbon/userprofile/edit.jsp?username=DOMAIN/demo_jbu&profile=default&fromUserMgt=true
Users are identified as DOMAIN\username so when I want to log in user from this DOMAIN, request goes to my AUTHENTICATOR implementation so I can manage authentication for users from this domain.
What is strange is, that if I use WSO2IS administration pages, I can set and read users's attributes well. And if I use SAML SSO authentication (have already set up service provider & claim mappings) for users from PRIMARY domain, everything goes fine and calling SP gets all attributes - mapped in WSO2IS administration here:
https://localhost:9443/carbon/application/configure-service-provider.jsp
If I use SAML SSO authentication, but I want to log user from my DOMAIN, SP doesn't get anything.
I can override this behavior in DefaultResponseBuilder, I can put into SAMLResponse anything I want, but I don't feel this approach is OK. Can anyone tell me, where to look for an error? What may be wrong? Where should I start looking for problems? I have already tried to debug it, and it seems it (SAML SSO/AUTHENTICATOR) doesn't find any claim for DOMAIN user.
Thank you in advance.
Josef
I think this is bug in Identity Server 5.0.0. When you are using SAML2 SSO, user can login to Identity Server with both username with domain name and username without domain name. Basically
bob and foo.com/bob must both works and returns the bob user's attributes from foo.com user store. However there is issue with IS 5.0.0, if secondary user store user login without domain name, Identity Server does not returns the user attributes. But, please try to login with foo.com/bob , Then it would return the user's attributes.
You can find the public jira. It contains source diff. It must be a simple fix and you even can compile the source and add fix in to the Identity Server.