You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The initial implementation of okta/okta-aws-cli is making use of an OIE organization with an OIDC Native Application paired to an Okta AWS Federation integration application. The Okta AWS Fed App makes use of a feature we call Web SSO token that is based on a device grant and user authentication. This use case is human and web browser oriented.
I have a proof of concept to implement a headless access use case in okta/okta-aws-cli. This makes use of an Okta Custom Authorization server paired with an IAM OIDC based IdP. This feature has existed in Okta for two or three years. Additionally, an Okta Service app is paired with the Okta custom authorization server via an authentication policy. Okta service apps allow for authentication with a secret provided by Okta, a private key provided by Okta, or a private key that is provisioned by the administrator of the Okta service app.
The POC's auth flow to receive temporary IAM credentials is as follows: an access token is requested for the service app , the request is signed with the secret key the operator controls. The Okta authorization server responds with a token if the request is valid. The Okta access token is then presented to AWS STS for temporary IAM creds using the AWS AssumeRoleWithWebIdentity mechanism. On AWS's back end, it communicates with the Okta custom authorization server in the OpenID Connect standard. These abilities between AWS and Okta exist today and the next step is to encapsulate them within the runtime of the okta-aws-cli so the operator doesn't have write shell scripts and do it on their own.
@jefftaylor-okta will be flushing out the interface and behavior details on how we expose this in the okta-aws-cli . This pinned issue can give the community an opportunity to give feedback on the feature as well.
The text was updated successfully, but these errors were encountered:
The initial implementation of okta/okta-aws-cli is making use of an OIE organization with an OIDC Native Application paired to an Okta AWS Federation integration application. The Okta AWS Fed App makes use of a feature we call Web SSO token that is based on a device grant and user authentication. This use case is human and web browser oriented.
I have a proof of concept to implement a headless access use case in okta/okta-aws-cli. This makes use of an Okta Custom Authorization server paired with an IAM OIDC based IdP. This feature has existed in Okta for two or three years. Additionally, an Okta Service app is paired with the Okta custom authorization server via an authentication policy. Okta service apps allow for authentication with a secret provided by Okta, a private key provided by Okta, or a private key that is provisioned by the administrator of the Okta service app.
The POC's auth flow to receive temporary IAM credentials is as follows: an access token is requested for the service app , the request is signed with the secret key the operator controls. The Okta authorization server responds with a token if the request is valid. The Okta access token is then presented to AWS STS for temporary IAM creds using the AWS AssumeRoleWithWebIdentity mechanism. On AWS's back end, it communicates with the Okta custom authorization server in the OpenID Connect standard. These abilities between AWS and Okta exist today and the next step is to encapsulate them within the runtime of the okta-aws-cli so the operator doesn't have write shell scripts and do it on their own.
@jefftaylor-okta will be flushing out the interface and behavior details on how we expose this in the okta-aws-cli . This pinned issue can give the community an opportunity to give feedback on the feature as well.
The text was updated successfully, but these errors were encountered: