I am integrating Okta in my React application for SSO. I use the following method to create token using redirect:
https://github.com/okta/okta-auth-js#tokengetwithredirectoptions
I am using https://www.npmjs.com/package/#okta/okta-auth-js package.
Users are directed to the Identity Provider (idp) in order to authenticate and then redirected to Okta once verification is successful.
The SSO works fine but when I keep the React application idle for sometime, I am getting the following error:
OAuthError - Unable to process the username transform. A required property is missing. Missing field email.
It looks like you have configured email as the incoming claim from your IDP but Okta can't find it in the incoming assertion/token.
Related
I have custom policies setup within our Azure AD B2C tenant to setup a SAML based signin SP initiated flow. On receipt of the response from the third party IDP I get the exception "The response has an invalid relay cookie".
I believe this is because the IDP's response is missing the InResponseTo property. Having spoken to said IDP, they are not able to send back the InResponseTo property in their response.
Is there a way to either remove the InResponseTo property from our initial request, OR is it possible to disable checking the InResponseTo attribute on receipt of the response?
I've successfully run a signin using the same custom policies in B2C, but using https://samltest.id/start-sp-test/ as the IDP instead, and can see the InResponseTo property returned in the response from here. So this is the only thing I have been able to identify as the a possible cause.
I know this is bad practice / a security flaw, but we are trying to prove we can get the identity flow working with this third party, with a view this will be fixed at a later date.
The application associated with client id 09ac92da-a796-4cd9-973b-c97756____ has no registered redirect URIs
Description
I followed the steps described in https://learn.microsoft.com/en-us/azure/active-directory-b2c/configure-ropc?tabs=applications.
When attempting to obtain the token in Postman using ROPC I'm getting
{
"error": "invalid_request",
"error_description": "AADB2C90007: The application associated with client id '09ac92da-a796-4cd9-973b-c97756____' has no registered redirect URIs.\r\nCorrelation ID: e85003c3-cfd5-43ad-a74b-efa5c1ea6525\r\nTimestamp: 2019-12-06 19:47:42Z\r\n"
}
I should not be asked for a redirect URIs.
My POST is as follows:
URL: ''https://mytenant.b2clogin.com/mytenant.onmicrosoft.com/oauth2/v2.0/token?p=B2C_1_ROPC_Auth"
username: some_username_of_a_user
password: its-password
grant_type: password
scope: openid offline_access 09ac92da-a796-4cd9-973b-c97756____
client_id: 09ac92da-a796-4cd9-973b-c97756____
response-type: token id_token
I didn't reproduce your issue by following this document. Here are the main steps for your reference.
1.Create a resource owner user flow
2.Register an application(It is an application under Azure AD B2C, not Azure AD)
3.Test the user flow
This error generally occurs because you still need to configure some application claims in the b2c directory user flow to allow complete access to the application.
You need to make sure that the right versions of the authentication are in the reply url (likely extension v2.0) and that the reply URL is configured in the application and in the code.
Please look to the documentation for the reply URL schema that you would need to follow: https://learn.microsoft.com/en-us/azure/active-directory-b2c/tutorial-register-applications?tabs=applications#register-a-web-application
If you still run into this issue let me know and I can reach out to the correct product team contacts, as sometimes this can happen due to breaking changes on our end.
I have setup my GSuite account as a SAML iDP for Cognito User Pools (not identity pools).
If i provide no attribute mappings a new user trying to signup via GSuite login gets the following error.
Error in SAML response processing: Invalid user attributes: email: Attribute is required.
However if I add an email mapping, the user can signup. But can't ever sign in again as they get this error (strange as email is writable by this app client)
Error in SAML response processing: Invalid user attributes: email: Attribute cannot be updated.
Ideas as to whats going on?
In browser, using Hosted UI.
It turns out I had made the email address immutable during CloudFormation setup. Even though the email is not being modified, it needs to be mutable.
You can determine the mutability of email via the following command.
aws --output table cognito-idp describe-user-pool --user-pool-id <user pool id> | grep -B6 -A7 " | email "
For anyone who is facing this issue when using SAML and AD as the identity provider, you have to configure Attribute Mapping.
Go to Attribute Mapping under Federation, Enter http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress for SAML attribute and Select Email fro User pool attribute
I had the error below randomly after being able to login the first time. Disabling and then deleting the user from the pool and allowing Cognito to recreate it fixed the issue for me. I assume there is an AWS bug here somewhere.
Error in SAML response processing: Invalid user attributes: email: Attribute cannot be updated.
I am implementing the Azure B2C preview in our mobile app but I am having trouble retrieving the application claims once the Signup policy has completed and the redirect_uri is called. I have specified the claims I need returned through the "Application claims" section of the policy blade and similarly through the other two policies (Sign-in and Profile) but I never receive a JWT along with the access code on the callback to the redirect_uri.
I have also tried HTTP and HTTPS in the redirect_uri and using the different response_mode settings but all i get is the code returned.
Am i missing something, or does the signup policy not support returning other claims at this point. I was planning on using them to send a welcome email to the new user.
I think i may have just realised - i need to make a call to the token endpoint to swap my code for the id_token and then i can get the claims.
So I am trying to setup Okta as an identity provider, and I want to login to an application using the Service Provider initiated workflow. I've setup the template SAML 2.0 application in Okta and setup the entry point and SAML certificate on the Service provider. The Service Provider initiates the workflow just fine, a popup opens with the Okta login dialogue. But once the login is complete I am taken into the Okta portal with a list of my apps. What should be happening is a re-direct back to the Service Provider so that it can use the userID to login the user there.
I followed the instruction here for setting up the IdP https://support.okta.com/entries/23364161-Configuring-Okta-Template-SAML-2-0-application
Here is what my config in Okta looks like
Application Label: App Name
Force Authentication: no
Name ID format: EmailAddress
Recipient: https://serviceprovider.com/_saml/validate/okta/
Audience Restriction: https://serviceprovider.com/
authnContextClassRef: Password Protected Transport
Destination: https://serviceprovider.com/_saml/validate/okta/
Response: signed
Assertion: signed
Request: uncompressed
Default Relay State: Leave blank since we are only doing SP initiated workflow
Post Back URL: https://serviceprovider.com/_saml/validate/okta/
Attribute Statements: none
Group Name: leave blank
Group filter: leave blank
I don't see any errors in the Okta portal or in the Okta administration panel, so I can't figure out why it is not completing the workflow and re-directing back to the SP.
Is there a place in Okta to see any errors that might be getting thrown by the process?
Anyone know what might be up?
I had a similar problem a while back. In my case, the "Rquest" was set to "compressed". changing it to "uncompressed" solved the issue. But in your case I see it is already "uncompressed"...
However, try to contact OKTA's support - they can help you out.
The answer is different depending on the type of SAML HTTP BINDING used for the SAML Authentication Request.
For HTTP Redirect Bindings you need to set the Okta Request to "compressed".
For HTTP POST Bindings you need to set the Okta Request to "uncompressed".