oidc: hydra as federated user auth for AWS Console/API

[SonOfBytes]

I'm looking to do a spike in using hydra as an ECS service that provides AWS Console/API federated services using Open Connect ID.

http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html

The first hurdle I hit was that it appears the when setting up an identity provider in AWS for Open Connect ID that it is hitting /.well-known/openid-configuration

This seems to be requesting a Thumbprint for the OIDC IDP

http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html

What is the best suggested way of delivering the requested thumbprint using hydra?

[aeneasr]

Currently on the run, but I don't think the oidc thumbprint is currently implemented. I'm open though to have that feature in Hydra, especially because it's a standard. I'll check the spec when I'm home. What would be even more awesome is a PR. You can ping me in gitter if you want to tackle it! Am 01.12.2016 um 17:22 schrieb SonOfBytes:

…

I'm looking to do a spike in using hydra as an ECS service that provides AWS Console/API federated services using Open Connect ID. http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html The first hurdle I hit was that it appears the when setting up an identity provider in AWS for Open Connect ID that it is hitting |/.well-known/openid-configuration| This seems to be requesting a Thumbprint for the OIDC IDP http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html What is the best suggested way of delivering the requested thumbprint using hydra? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#315>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADN1epj4gX9lr-dzk-uJ_U17CP8rbn5aks5rDvRMgaJpZM4LBl1F>.

[SonOfBytes]

I'm quite new to iidc and hydra - so I'll probably have the fog of ignorance to work through :P

Looking at a sample else where this appears to be the broad format

{
  "issuer": "https://some-auth-service.com/",
  "authorization_endpoint": "https://some-auth-service.com/authorize",
  "token_endpoint": "https://some-auth-service.com/oauth/token",
  "userinfo_endpoint": "https://some-auth-service.com/userinfo",
  "jwks_uri": "https://some-auth-service.com/.well-known/jwks.json",
  "scopes_supported": [
    "cut_for_brevity"
  ],
  "response_types_supported": [
    "code",
    "token",
    "code token"
  ],
  "response_modes_supported": [
    "query",
    "fragment",
    "form_post"
  ],
  "subject_types_supported": [
    "public"
  ],
  "id_token_signing_alg_values_supported": [
    "HS256",
    "RS256"
  ],
  "token_endpoint_auth_methods_supported": [
    "client_secret_basic",
    "client_secret_post"
  ],
  "claims_supported": [
    "cut_for_brevity"
  ]
}

[aeneasr]

Jup that looks about right, still going to need the jwks discovery, which should also sort of look like this document (but point to the jwk sets instead)

[SonOfBytes]

Ref: https://openid.net/specs/openid-connect-discovery-1_0.html

[aeneasr]

this is now implemented