Passing code challenge to Cognito Federated Identiy via Amplify [Okta] - amazon-cognito

I Integrated Cognito Userpool with Federated Identity [Okta - As Secure Web Authentication]. The flows works fine with Authorization Code Flow without PKCE (Using Amplify with Angular).
Created a similar app as SPA(in Okta), to enable PKCE and integrated with Cognito federated identities.
When we redirect to Hosted UI, the challenge is getting passed to hosted UI in the URL.
But after it redirects to okta, it is throwing this error.
pkce code challenge is required when the token endpoint authentication
method is 'none'
Is there any additional configuration required in Cognito to pass code-challenge to Okta.
I am using Authorization Code flow in Cognito and Okta.
Attaching the configuration in Okta.
Attaching the configuration in Cognito

There was a mistake in my understanding. Communication between Cognito & Okta is service to service call, which should have been performed as Client Credential Grand Flow. There we don't enable PKCE in Okta.
PKCE is enabled for Client (Web or Mobile App) to Service Authentication.
When we create App Client without client secrete, Amplify enables PKCE in frontend.

Related

Can I federate Cognito with "client credentials" flow (or other way to trust a server-side application authenticated elsewhere?)

I have an AWS REST API Gateway with Cognito authentication using the client credentials grant.
We have been creating new clients by hand and sharing the ID/secret with people who need to use our API. They send the ID/secret and "grant_type=client_credentials" to Cognito, it gives them a bearer token and they use the API with the token. All fine so far. (It is a CLI tool running on a schedule, not accessed by a browser. I specifically need to avoid any sort of "go to the browser to login".)
Now, we have a new "island" of users who have a local OIDC (Azure AD) provider that can issue them a bearer token from a curl to an endpoint.
Is there a way to make Cognito accept those tokens??
I have tried federating Cognito with a different oidc provider (I don't have AD, but a different provider), getting myself a bearer token from it and sending it to the API GW, and I just get 401'ed. I don't know if there is something I'm doing wrong or if it's not possible.
(Things I might be doing wrong seems to be a long list! I need to create a client in the other provider and add it's ID/secret/URL to Cognito, that works. I used the same client ID/secret to generate my bearer token. But when I'm in client creds flow in Cognito, I need to set a custom scope. Do I need to add that scope to my initial request to the other provider (The API GW doesn't require a scope, it is just a mock endpoint at the moment in testing). The client_id= in the request is for the client in the other provider, not the Cognito client ID. Should I set it to the Cognito client ID?)
OR do I need to write a custom authenticator for the API GW to validate the token? (Decode JWT, Check : issuer is allowed and signature is valid.)
And not use Cognito at all for these other users.
(If it was an HTTP API, I think I can create a JWT authoriser and it does it all for me, but it isn't and there are some features on REST APIs not available on HTTP (like WAF))
Sorry it's a bit short on details. I could spend days copy/pasting all the configs from ID provider/Cognito but if it fundamentally won't work I wasted my time!
(After trying it, I think maybe federation only works for actual users with a browser based login flow, not clients with a CLI flow. I can't find anyone saying client credentials flow does work anyway!)
Cognito is using the authorization server role. So in all cases, the tokens returned to client applications will be issued by Cognito. These apps will never deal with Azure AD tokens. Multiple types of client can coexist together:
CLIENT CREDENTIALS GRANT
Clients who use this flow might represent B2B connections. The business partner must always get Cognito tokens directly, and no federation is used here.
AUTHORIZATION CODE GRANT
Browser clients will use this flow, and you can configure Cognito to implement authentication by making a second OIDC Connect redirect to Azure AD.
My blog post provides a walkthrough on how settings are configured. Cognito will act as a client of Azure AD and use a scope such as openid profile email.
After a user login, Cognito will receive Azure AD tokens, validate them, then issue its own tokens. Nothing will change in the API gateway, which will continue to verify Cognito tokens.

Securing an API with SAML SSO / OAuth2.0

Alright, so I'm having a hard time understanding a proper flow here for my setup.
Goal
I want to have a proper SSO flow for my SPA app that can authenticate users into an API.
Context
I have a React application that is intended to use an Okta porta that offers both SAML (preferred) and OIDC for SSO flows. I've wrapped my static sources in a web server that serves them, and that server has a middleware that checks for cookies, and if one doesn't exist, I redirect to the IDP (Okta) for login. This all works fine for now.
Currently, my API sits on that same server, which I intend on moving to a separate server to scale independently of the website. My API must also allow other machine clients (services) to call into it, so I implemented a service account flow that uses client ID and secret as the authentication measure.
In general, my intended flow looks like this:
User navigates to my website (unauthorized) -> Web Server -> Redirect to IDP -> Assertion Callback flow -> Generate JWT session cookie -> Web Application makes API call -> API Server auth middleware validates cookie / bearer token.
The problem.
The details of how the JWT access token is generated is where I'm stuck. Currently, my webserver receives the SAML assertion and generates a JWT, which is not the same JWT claims logic as the service accounts (bleh). I'm thinking of implementing an Auth service instead to centralize the token generation flows.
For the Auth Service, I've looked into OAuth2.0 and it seems like just the right approach for what I need. With that said, I can't find much information on patterns to follow for SAML assertion -> OAuth2.0. I saw an IETF draft for saml2-bearer grant-type, but it seems dead in the water. I'm also unsure about the general consensus on custom implemented OAuth2.0 grant types.
What does a proper flow look like? I have a couple of scenarios in mind:
SAML Service Provider within the same service as the Auth
Service. On lack of SSO session, my application redirects to my Auth service, which then redirects to my IDP. The IDP calls my SP (the auth server) with the assertion, the auth service generates a token, then my auth service redirects back to the webserver with a cookie placed in the response headers.
SAML SP as the webserver Since the webserver is the only system that needs to use the SSO, I could just keep the SAML flow within that process. Once my webserver receives the SAML assertion callback, my server makes a call to an endpoint service with the assertion claims, and then my auth service returns the access token in a JSON response.
Something else, like OAuth2.0 authorization code flow with PKCE for the web application. Or OIDC instead of SAML for SSO.
OIDC sounds like the right choice for you as APIs are involved. OAuth is designed to secure APIs' compared to SAML which is built for enterprise SSO.
You can integrate your SPA with Okta using OIDC. Okta provides SDK's for varies platforms to make it easier for you to do so. You can find SDKs' here:
https://developer.okta.com/code/angular/okta_angular_auth_js/
Once you get an ID token and Access token from Okta after OIDC flow, you can use the access token to access external API's. Your API resource server or the API gateway can validate the access token. Again Okta provides SDK's to verify access tokens: https://developer.okta.com/code/dotnet/jwt-validation/

How to use Firebase Authentication with Okta?

I am currently using Firebase Authentication in my app using the built-in OIDC providers (Google, Facebook etc.). Is it possible to use Okta as an additional OIDC provider with minimal modifications to my app, meaning Okta should behave just like any other built-in provider? Firebase Auth apis, such as firebase.auth().currentUser and firebase.auth().onAuthStateChanged() should still work.
The doc page for Custom Authentication talks about getting a custom token from an auth server, but does not clarify if that's an OAuth access token. Is there an example of Okta integration or a generic OIDC integration that works seamlessly with Firebase auth?
There's no built-in Okta provider for Firebase Authentication, but if you have an existing authentication flow for it, it's fairly easy to integrate it into Firebase as a custom provider.
It's a 6 step process:
You gather the user credentials on the client.
You pass those credentials to a trusted environment, either a server you control, or Cloud Functions.
On the server you verify that the credentials are correct according to Okta, typically by calling a server-side API they provide with a key you provide.
You then use the results of that call to mint a new ID token for the user. This is a JWT, not an OAuth access token.
You pass back that ID token from the server to the client.
The client then calls firebase.auth().signInWithCustomToken(token) with the ID token, to sign in to Firebase Authentication.

Auth0 as front end to log in Cognito users

I have an Android app and an API secured with Auth0.
I'm developing an app for a new client, who has a large Cognito user pool.
Is it possible to use my current Auth0 setup to log in Cognito users via email/password and receive a Auth0 JWT?
I don't want to create a new Auth0 user for each Cognito user. At least not explicitly.
Thanks
If I understand you correctly, you want to use Auth0 as a service provider and AWS Cognito as an identity provider. In theory, you can use SAML protocol to achieve that. Try the following:
Configure Auth0 as SAML service provider. https://auth0.com/docs/protocols/saml/saml-sp-generic
Configure AWS Cognito AS Identity provider: https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-managing-saml-idp-console.html
Then, once you initiate the login flow in auth0, users will be redirected to AWS Cognito for user authentication. After successful user authentication, AWS should redirect the user Auth0 with SAML Assertion. In that stage, Auth0 will validate the assertion and will issue a JWT token. The user will be redirected to your application with JWT. Note that if this is the first login, auth0 will create a user profile.
https://auth0.com/docs/protocols/saml
The following AWS documentation explains how to configure auth0 as IDP.
https://aws.amazon.com/premiumsupport/knowledge-center/auth0-saml-cognito-user-pool/

REST API oauth2 type authentication using AWS Cognito

I have a rest api in nodejs. my mobile app will consume my rest api. Can i implement oauth2 type authentication using aws cognito for my mobile app? I need resource owner password grant if i implement oauth2.
Amazon Cognito's Federated Identity feature is not an authentication provider. It vends AWS credentials for well known providers like Facebook, Google, Cognito User Pools, etc. or for custom developer providers. These custom developer provider can use any authentication protocol as long as they talk to our services from the back end and use the OpenId tokens vended in back end from their mobile apps. You can read more about this here.
Cognito User Pools however is an authentication provider and vends OpenId tokens once the user is authenticated. These tokens can also be exchanged for AWS credentials using the federated identity flow.