Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Documentation for Dynamic client registration #1220

Closed
ghost opened this issue Apr 4, 2017 · 5 comments
Closed

Documentation for Dynamic client registration #1220

ghost opened this issue Apr 4, 2017 · 5 comments

Comments

@ghost
Copy link

ghost commented Apr 4, 2017

Is there any kind of documentation available for the Dynamic client registration feature?

@jricher
Copy link
Member

jricher commented Apr 4, 2017

From the client side there's configuration information here: https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/wiki/Client-configuration

From the server side there's not much to configure, as it conforms to the RFCs: https://tools.ietf.org/html/rfc7591 https://tools.ietf.org/html/rfc7592

@ghost
Copy link
Author

ghost commented Apr 5, 2017

How do I configure an Initial Access Token which is required to dynamically register clients?

We are planning to require mobile app instances to register using the dynamic client registration endpoint. Software vendors get an Initial Access Token they use when registering the instances.

We also would like to restrict allowed algorithms for signing JWKs to Elliptic Curve cryptography algorithm.

@jricher
Copy link
Member

jricher commented Apr 5, 2017

There's not directly built in support for the initial access token in the server or client libraries at this time. You could configure it on the server by putting an OAuth resource filter in front of the dynamic registration endpoint and then adding custom code to determine whether to validate the incoming request or not. Similarly with the client you'd need to create a custom dynamic client service that registers with the provided token.

A better approach might be to use a software statement instead. The software statement would allow you to do both of the above by providing a semi-unknown (and unforgeable) credential that you can hand to developers, which would also have the benefit of locking down the registration including things like limiting EC algorithms. Support for software statements was added in 1.3.

@ghost
Copy link
Author

ghost commented Apr 10, 2017

We tried to use a software statement like this

eyJhbGciOiJFUzI1NiJ9.ewoJImNsaWVudF9uYW1lIjogIkV4YW1wbGUgUEhSIENsaWVudCIsCgkic29mdHdhcmVfaWQiOiAiYmxhYmxhIiwKICAgICAgICAiaXNzIjogImh0dHA6Ly9hcnRlbWVzaWEubG9jYWwiLAoJImp3a3MiOiB7ImtleXMiOiAKCVsKCQl7CgkJICAia3R5IjogIkVDIiwKCQkgICJ1c2UiOiAic2lnIiwKCQkgICJjcnYiOiAiUC0yNTYiLAoJCSAgImtpZCI6ICJob3BsYWEiLAoJCSAgIngiOiAiU1lxazNOdGxIQU0yWkNQcUpCWmZiTXY4a0FCTlpLenQyaXR1Ql9pV053NCIsCgkJICAieSI6ICJ5Y0x3SWtSMXpXRWN3cnhCbG9fYngwMmZtVmRCNmhWRzVfRHUwY3c0bnZBIiwKCQkgICJhbGciOiAiRVMyNTYiCgkJfQoJXX0KfQ.xfdL9uXUfXcn2ayr8AUhWLS73L5gEC5oKjAWmnSf6DTpdQU6JalDZ8B9sq2Oq2udkWZf1abkpElQnw97H3KFxQ

Here's the decoded payload

{
  "client_name": "Example PHR Client",
  "software_id": "blabla",
  "iss": "http://artemesia.local",
  "jwks": {
    "keys": [
      {
        "kty": "EC",
        "use": "sig",
        "crv": "P-256",
        "kid": "hoplaa",
        "x": "SYqk3NtlHAM2ZCPqJBZfbMv8kABNZKzt2ituB_iWNw4",
        "y": "ycLwIkR1zWEcwrxBlo_bx02fmVdB6hVG5_Du0cw4nvA",
        "alg": "ES256"
      }
    ]
  }
}

What happens is there's a ParsingException because in DynamicClientRegistrationEndpoint https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/blob/master/openid-connect-server/src/main/java/org/mitre/openid/connect/web/DynamicClientRegistrationEndpoint.java#L691 it is assumed that the JWKS is in String format. It ends up being a JSONObject and this causes the Exception.

How is the JWKS supposed to be presented?

If I change it to use

case JWKS:
		newClient.setJwks(JWKSet.parse((JSONObject) claimSet.getClaim(claim)));
		break;

it works.

@jricher
Copy link
Member

jricher commented Apr 10, 2017

You're right, that is supposed to be a JSON object, good catch! We should be able to fix that easily before release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant