我可以将 Cognito 与“客户端凭据”流联合（或其他信任在别处验证的服务器端应用程序的方式吗？）

Question

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!)

Answer 1

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.