I'm trying to use Shopify as an AWS Cognito User Pool "federated identity provider". Ostensibly, it seems to follow the OIDC protocol. However, there seems to be scant information on the format of the ProviderDetails field in the AWS API call, and I can't seem to figure out how to correctly pass the Issuer for Shopify. I've tried to do it through the console as well, but keep getting the message:
Discovery returned no results. Check the issuer and run discovery again or manually add the required fields below.
I suspect that, due to Shopify's multitenancy model, I'll never get a single set of OIDC parameters -- it seems to suggest there is a different URL for each shop.
Is there documentation on either (a) how to set up Shopify as an OIDC provider -- including Issuer, Authorization Endpoint, Token Endpoint, etc. -- or (b) why Shopify does not match the OIDC standard?
Related
I'm working on setting up Google as an IdP for my Cognito User Pool. I'm following this AWS guide.
Even though I'm only selecting "non-sensitive scopes" (opened, profile, email) when configuring the OAuth app, Google is then saying that it requires verification.
The AWS guide linked above says:
For Authorized domains, enter amazoncognito.com.
I've entered this as an authorized domain, but since I've done that, Google is now saying that in order to verify the app, I need to "verify ownership of the following domain" (amazoncognito.com). Clearly, I cannot do this, as I do not own that domain.
Am I missing something here? It seems that AWS and Google have set this up in a way that makes it impossible to verify a Google OAuth app for use with Cognito.
We utilize AWS Cognito to perform all authentication in our product. Users can try to login using one of the Facebook, Google, Amazon, Microsoft accounts. So we need to identify the user who tried to log in using which Identity Provider or bearer token utilized. So we will store those pieces of information. Is there any way that we can get provider Infos something like its suffix, and so on?
It will be stored as I mentioned below.
AuthByEmail :1,
ByMobile: 0,
AWSIPName: Google,
AWSClientName:client101,
Suffix: Google_client101_jhon#client101.com
Thanks
If the request was made with temporary security credentials obtained by web identity federation, you can find an element called webIdFederationData that lists information about the identity provider in the respective CloudTrail events’ userIdentity. Attributes for this element are:
federatedProvider – The principal name of the identity provider (for example, www.amazon.com for Login with Amazon or accounts.google.com for Google).
attributes – The application ID and user ID as reported by the provider (for example, www.amazon.com:app_id and www.amazon.com:user_id for Login with Amazon).
You can learn more about the structure and content of the CloudTrail userIdentity in different cases here.
I would like to use firebase auth to secure my AWS AppSync graphql api, as opposed to something like Cognito. There are several reasons behind this like pricing and us already using some other firebase services.
The only viable solution I can see atm is to somehow pass firebase user token to my AppSync graphql api and validate it through OpenID Conneect / OIDC.
I was not able to figure this out nor find any guides on the topic, so wanted to ask here if it is even possible, if so, could any examples be provided or perhaps use-full references?
Here are related fields that need to be provided to AppSync in terms of OpenID connect data https://docs.aws.amazon.com/cdk/api/latest/docs/#aws-cdk_aws-appsync.OpenIdConnectConfig.html
Do these exist for firebase auth?
Update: I was able to find some documentation on firebase token verification https://firebase.google.com/docs/auth/admin/verify-id-tokens#verify_id_tokens_using_a_third-party_jwt_library
I believe following URL is what needs to be used as OpenID url setting in AppSync https://www.googleapis.com/robot/v1/metadata/x509/securetoken#system.gserviceaccount.com
However AppSync documentation states that they append /.well-known/openid-configuration to such url and when I do that to googleapis url above, it throws 404.
AppSync expects an OpenID Connect Provider (OP). More specifically, it wants the OP's issuer; the rest of metadata is retrieved based on that. From AppSync doc:
OPENID_CONNECT Authorization
This authorization type enforces OpenID Connect (OIDC) tokens provided by an OIDC-compliant service.
Your application can leverage users and privileges defined by your
OIDC provider for controlling access.
An Issuer URL is the only required configuration value that you
provide to AWS AppSync (for example, https://auth.example.com). This
URL must be addressable over HTTPS. AWS AppSync appends
/.well-known/openid-configuration to the issuer URL and locates the
OpenID configuration at
https://auth.example.com/.well-known/openid-configuration per the
OpenID Connect Discovery specification
Firebase is (mostly) a middleware. Even though you could have a user account be residing in Firebase, a more typical use case is to plug in some provider such as Google or Microsoft into Firebase. You could then use Firebase APIs to perform various operations without having to know the details of the underlying provider.
Whether acting as middleware or as an identity store with users in Firebase, it's unclear if Firebase is an OIDC-compliant provider. OpenID publishes OIDC conformance tests as well as entities that have been certified. The only Google entity on the latter list is a "Google Federated Identity". Certification aside, Firebase does issue a signed JWT that according to them is morally equivalent to id_token in OIDC:
ID token verification
If your Firebase client app communicates with
your backend server, you might need to identify the currently
signed-in user on your server so you can perform server-side logic on
their behalf. You can do this securely by using ID tokens, which are
created by Firebase when a user signs into an Firebase app.
ID tokens
conform to the OpenID Connect spec and contain data to identify a
user, as well as some other profile and authentication related
information. You can send, verify, and inspect these tokens from your
own backends. This allows you to securely identify the currently
signed in user and authorize them into your own backend resources.
If you create a Firebase project, then authenticate via that and examine the issued token, you'll see the iss (Issuer) key in the token payload. It has a value of https://securetoken.google.com/<Firebase projectId> and that's the URL needed by AppSync.
You can confirm that OIDC metadata is available by concatenating /.well-known/openid-configuration with https://securetoken.google.com/<Firebase projectId> and doing a GET on the resulting URL. The expected response should look like this:
{
"issuer": "https://securetoken.google.com/<Firebase project id>",
"jwks_uri": "https://www.googleapis.com/service_accounts/v1/jwk/securetoken#system.gserviceaccount.com",
"response_types_supported": [
"id_token"
],
"subject_types_supported": [
"public"
],
"id_token_signing_alg_values_supported": [
"RS256"
]
}
I will want to use Okta as SAML 2.0 based IDP, AWS Cognito as service provider, and Cognito user pool to have federated IDP configuration.
I have followed all the steps mentioned in AWS sites listed below -
https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-saml-idp.html
https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-integrating-3rd-party-saml-providers.html
https://aws.amazon.com/blogs/mobile/amazon-cognito-user-pools-supports-federation-with-saml
Okta does not provide any support or documentation - https://support.okta.com/help/answers?id=9062A000000QucAQAS&feedtype=SINGLE_QUESTION_DETAIL&dc=xSAML&criteria=OPENQUESTIONS& .
Please note that I have tried Okta as IDP, established trust with AWS IAM, and using Okta user logs in to my AWS account. This works fine following the detailed documentation provided by Okta. However, my need is different wherein I would like to use Okta as SAML IDP in my AWS cognito user pool.
Any detailed documentation containing configurations to be done at both ends i.e. AWS and Okta, will be helpful.
I did setup Okta with Cognito through SAML with the following:
Okta side:
Single sign on URL will be your cognito SAML endpoint in the form of:
https://<yourDomainPrefix>.auth.<region>.amazoncognito.com/saml2/idpresponse (see under your user pool, "App integration" -> "Domain name" for the first part of the URL).
Audience URI (SP Entity ID) will be the URN of your cognito user pool: urn:amazon:cognito:sp:<yourUserPoolID> (see your user pool "General Settings" for that pool ID).
Attribute statements, you want to add whatever attribute you set as mandatory in your pool, in my case it was email.
Cognito side - User pool:
Federation -> Identity providers: Choose SAML and import the metadata.xml from Okta.
get to your App client settings, under App integration and enable the newly created IDP
Cognito side - Identity pool:
Under authentication providers, SAML tab, you'll be able to check the Okta provider checkbox as you mentioned that you already have it as a trusted provider under IAM.
That should be about it.
Resources that were of help: https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-saml-idp.html
EDIT: It seems that clarification was required on the Audience URI/Audience Restriction Okta setting. As Julien below mentioned is in the form of urn:amazon:cognito:sp:region_randomid (ie. urn:amazon:cognito:sp:eu-west-1_SdsSdwSD3e), you don't need to add yourself the region.
Disclaimer: I'm not a SAML expert
We had to face the same problem here.
After authentication in Okta we were redirected to the Cognito login screen.
I tried to follow the advice from WenWolf with no success.
I analyzed the SAML flow using the SAML-tracer extension in Firefox.
An error message was hidden in the redirect URI after the assertion POST.
GET https://XXXXX?error_description=Error+in+SAML+response+processing%3A+Audience+restriction+in+SAML+Assertion+does+now+allow+it+for+urn%3Aamazon%3Acognito%3Asp%3Aeu-west-1_YYYYYYYY+&state=e4314f8a-e321-4302-91fe-2a4657a9c582&error=server_error HTTP/1.1
Which gives you :
Error in SAML response processing: Audience restriction in SAML Assertion does now allow it for urn:amazon:cognito:sp:eu-west-1_YYYYYYYY
To fix it in Okta:
Change the Audience Restriction field in Okta by replacing the value initially recommended in the documentation and the blog
urn:amazon:cognito:sp:IDFoundInAppIntegrationAppClientSettings
by the value indicated in the error message
urn:amazon:cognito:sp:eu-west-1_YYYYYYYY
This ID also appear in the auto-generated group in Cognito General settings>Users and groups
PS: Keep the other advices on NameId and required attribute mapping that needs to be consistent on both side.
I am trying to use the OpenID framework supported by Paypal to tie the credentials in with the AWS Cognito service.
If I compare the configuration from Salesforce
https://login.salesforce.com/.well-known/openid-configuration
to the configuration at Paypal
https://www.paypal.com/.well-known/openid-configuration
the Paypal configuration is missing the jwks_uri element which is a REQUIRED element of the OpenID Provider metadata per OIDC specification and AWS uses the keys at that URI to verify the id tokens.
Is there a different url I should be using for login with Paypal to work with OpenID?
Is there any other way to get Login with Paypal to work with the AWS Cognito service with works well with other OpenID providers?
Paypal is not OpenID Connect compliant:
as you mention the Discovery document lacks required entries, but:
the ID token is signed with a symmetric key this means that no JWKS URI is actually needed since no public/private keys are used (and publishing the symmetric key on that URI defeats the purpose)
but apparently it is not the client secret that is used to sign the ID token as verification with that fails
there's no sub claim in the ID token
the exp claim is not set to an absolute timestamp but a relative timeout
Since Amazon Cognito works with OpenID Connect compliant providers, Paypal is not going to work.