In the scenario you describe, you are only going to get back an OIDC ID Token, OAuth2 Access Token, and OAuth2 Refresh Token from Cognito for use with and trusted by services/APIs that have a trust relationship with Cognito. This is the end result of the OIDC Authentication Flow that you or your application code…
Glad you find it useful.
Cognito is an OpenID Connect Provider. The OAuth2 Token Endpoint you would be getting the OAuth2 Access Token back from would also provide the OIDC ID TOken and optionally a OAuth2 Refresh Token. Don’t forget to include “openid” in the list of requested scopes — it…
This is a bit after the fact, but very relevent. I recently wrote a guest blog post on the Ping Identity blog about how to approach this topic. See .
This will eventually be a three part series.
Generally, I have found that they are not familiar with these terms. I have also found that application authorization is not well understood nor has much structure been put around it. By structure, I mean an attempt to define internal standards at the enterprise level or consistently manage it — every application team is left to solve the problem on…
If you keep reading, I address that use case with OAuth2 Authorization Code Grant (or OIDC Authorization Code Flow). Furthermore, you may want to read .
Hi Josh. Thanks for the interest. Glad you find the article useful. Writing this Kerberos series was part of my own efforts to make sure I understood Kerberos.
The preauthentication mechanism is formalized in RFC 6113. It points back to the use of an encrypted timestamp for preauthentication as outlined in the Kerberos v5…
In most use cases, I recommend the OpenID Foundation’s AppAuth libraries. See .