FHIR Chat · Dynamic Client Registration · smart

Stream: smart

Topic: Dynamic Client Registration

Grahame Grieve (Sep 21 2017 at 04:51):

@Josh Mandel I am getting around to looking at Dynamic Client Registration, which Smart App Launch and the back end services spec recommends that I use. It seems to me that there's a little more to say than 'just use it'. Specifically, what token_endpoint_auth_method values map to the 3 options made available by the Smart specs?

Grahame Grieve (Sep 21 2017 at 19:59):

also, concerning 'iss', the backend services spec says "The service's issuer URI, as registered with the EHR's authorization server" - but dynamic client registration doesn't describe this, so we need a call out in the back end services spec to describe exactly how this works if we want it to work

Grahame Grieve (Sep 21 2017 at 22:58):

I used "issuer" in the json for the registration request

Grahame Grieve (Sep 22 2017 at 11:43):

so I'm not sure about using Dynamic Auth. There's 3 different modes:

• Confidential Client
• Public Client
• Backend Services Client

Grahame Grieve (Sep 22 2017 at 11:44):

here's what I think the 3 registrations look like:

Grahame Grieve (Sep 22 2017 at 11:46):

Confidential Client:

{
  "client_name" : "{name}",
  "redirect_uris" : ["{url}"],
  "client_secret_basic" : "client_secret_basic",
  "grant_types" : "authorization_code",
  "response_types" : "token"
}

Grahame Grieve (Sep 22 2017 at 11:46):

Public Client:

{
  "client_name" : "{name}",
  "redirect_uris" : ["{url}"],
  "client_secret_basic" : "client_secret_post",
  "grant_types" : "authorization_code",
  "response_types" : "token"
}

Grahame Grieve (Sep 22 2017 at 11:47):

Backend Services Client:

{
  "client_name" : "{name}",
  "issuer" : "{issuer}",
  "jwks" : {
    ...
  }
  "client_secret_basic" : "client_secret_post",
  "grant_types" : "client_credentials",
  "response_types" : "token"
}

Josh Mandel (Sep 22 2017 at 13:36):

token_endpoint_auth_method

• public clients: none
• confidential clients (symmetric secrets): client_secret_basic
• backend services asymmetric client: private_key_jwt (I suppose -- it seems to fit fine)

Josh Mandel (Sep 22 2017 at 13:38):

Re: issuer, we could instead just have the client register a jwks_uri with the server (this is supported by dynreg), but it means that a server really doesn't have any use for the issuer property in the signed token.

Josh Mandel (Sep 22 2017 at 13:39):

"client_secret_basic" : "client_secret_post",

This looks like an error in your payload. I'd expect to see

"token_endpoint_auth_method": "client_secret_basic"

Josh Mandel (Sep 22 2017 at 13:40):

And, er... for the first two cases, response_type should be code.

Josh Mandel (Sep 22 2017 at 13:40):

(See OIDC dynreg Section 2.1)

Grahame Grieve (Sep 22 2017 at 20:54):

I don't follow the logic for response_type being different for the first 2 cases, since the actual response is the same in all 3 cases (except for no openid element)

Grahame Grieve (Sep 22 2017 at 20:55):

I am very much against using jwks_uri for issuer because of this:

Grahame Grieve (Sep 22 2017 at 20:55):

The "jwks_uri" and "jwks" parameters MUST NOT both be present in the same request or response.

Grahame Grieve (Sep 22 2017 at 20:56):

"client_secret_basic" : "client_secret_post"

Grahame Grieve (Sep 22 2017 at 20:56):

that was a s typo preparing my posts

Grahame Grieve (Sep 22 2017 at 20:57):

so I hope that this is enough to be convincing that we actually need to say this stuff in the spec

Last updated: Apr 12 2022 at 19:14 UTC