1. OpenID Foundation Avatar OpenID Foundation
  2. WGs
  3. connect
  4. Issues

Relax behaviour around automatic client registration to permit other usecases

Issue #1606 resolved
Tobias Looker created an issue

The federation specification defines a useful way for a client to avoid explicit registration by using a client id that is resolvable to the clients metadata. This mechanism even though it is defined in the federation spec has applications beyond just federation for instance within the OIDC4SSI. The issue is that the current text in the federation spec is quite restrictive around other characteristics that a client must have to support automatic registration, namely using the signed request object with a key appropriately associated back to the clients metadata. The suggestion is that the usage of the signed request and key validation to the clients metadata should be an option (and probably required for federation usecases) but not required for all clients wanting to use automatic registration for other purposes.

Comments (27)

  2. Michael Jones

    @John Bradley - I’d like to hear your thoughts on this. What will go terribly wrong if the client doesn’t demonstration possession of its signing keys?

  3. David Waite Account Deactivated

    I’ve wondered why this requirement is there in federation as well, and queried about it previously on Connect calls.

    Historically there has been a preference not to sign authentication requests, as validating signatures from anonymous parties makes denial-of-service attacks an order of magnitude more effective.

  5. Tobias Looker reporter

    Do we need to require a request object in the case we aren’t signing it though? I’d prefer in this case we support a simpler request structure e.g no object and just simple query parameters

  6. Vladimir Dzhuvinov

    Would you elaborate what particular OAuth flow(s) you envision with this “relaxed” automatic registration? Also, whether and how the client will be authenticating? This context is important.

  7. Tobias Looker reporter

    A simple example is a public client that is going to use the authorization code flow without any formal client authentication mechanism beyond the fact that it must have the ability to receive the authorization code via a redirect uri that is registered against the client which is determined via their resolved metadata. IMO automatic registration (or what was termed client discovery in 1589) is describing a new way for the AS to come to understand who the client is, how the client intends to authenticate to the AS should be described in its metadata instead of the mechanism “automatic registration” requiring a specific client authentication method.

  8. Giuseppe De Marco

    We assume that the signed object is a requirement of the automatic registration, as confirmd also here
    https://bitbucket.org/openid/connect/pull-requests/289#Lopenid-connect-federation-1_0.xmlT3733

    I believe that removing the requirement of the signed JWT as the request object makes OIDC Fed more closer to oidc core implementations already in production.
    A client makes an authz request as it used to do, then magic may happen if the OP supports the automatic client registration and the RP has published its EC at .well-known/openid-federation endpoint. This enables that the only requirement to enable Federation 1.0 in a legacy implementation would be the publication of the EC at the previous endpoint.

    We know that many federations and implementers doesn’t really like the signed authz request and these are the audience of this brand new spec (the people). I don’t see any concrete benefit making signed request as mandatory. I believe that we may change our mind on this.

    to clarify the italian implementation: both SPID and CIE id makes the signed authz request as mandatory because each OP must be sure that the request is verifiable before authenticating an user.

    The signed request object may became an implementation option. I’d leave this door open with in mind a concrete strategy to get the maximum integration possibilities in OIDC Federation for legacy implementations … And more, also for SIOPv2 (that’s not legacy at all).

    ‌

  9. Torsten Lodderstedt

    @Tobias Looker do you want to remove the requirement for client authentication in advance of the authentication request at all? Do you want to use federation for public clients?

  10. Giuseppe De Marco

    we may discuss if the unsigned authz request is good enough to register a client

    I think that's something to the trust framework adopted and not to the federation specs as a requirement

  11. Roland Hedberg

    The “relaxed” automatic registration means you have anonymous clients. You have absolutely no idea who the client is. Is that what you want.

  12. Tobias Looker reporter

    I dont believe that is universally true, for example a client interacting through the front channel (making an authorize request) will have to use a redirect_uri that is present in the metadata for the client which allows the AS to establish confidence in who the client is.

  13. Roland Hedberg

    That’s after the fact. You have already done the user authentication and all processing around that before you realise that the client you talked to is not the one you thought.

  14. Tobias Looker reporter

    How so? The AS knows the redirect uri being requested for the response the moment they receive the request, this can be validated against the client metadata resolved from the client id and the AS can reject the request before any further interaction e.g user auth

  15. Roland Hedberg

    Anyone can send a request with another RP’s client_id and redirect_uri, right ?.

    The OP can use the provided client_id to verify the redirect_uri but there is no way the OP can verify that the sender is the one that ‘owns’ the redirect_uri/client_id unless you have client_authentication or proof-of-possesion of keys connected to the request.

  16. Giuseppe De Marco

    @roland probably we may discuss if we want provide public and confidential clients in Federation, considering the signature of the authz request only for the confidential one.
    I start from some requirements we have in the mobile apps and eid wallets

  17. Torsten Lodderstedt

    The OP can use the provided client_id to verify the redirect_uri but there is no way the OP can verify that the sender is the one that ‘owns’ the redirect_uri/client_id unless you have client_authentication or proof-of-possesion of keys connected to the request.

    It is even worse: if the redirect URI is a custom scheme or uses a device local address, the code will be delivered to whoever controls that local endpoint on the device. Exchanging that code then for an access token is easy since the client is public and the attacker know the PKCE verifier (if used).

  18. Tobias Looker reporter

    Anyone can send a request with another RP’s client_id and redirect_uri, right ?

    Agreed is this not common for all public clients though even ones not using auto client registration? Are you saying all public clients should be considered anonymous?

    The OP can use the provided client_id to verify the redirect_uri but there is no way the OP can verify that the sender is the one that ‘owns’ the redirect_uri/client_id unless you have client_authentication or proof-of-possesion of keys connected to the request.

    Is the client not authenticated when it goes to exchange the authorization code at the token endpoint provided we assume that the redirect was not intercepted?

    It is even worse: if the redirect URI is a custom scheme or uses a device local address, the code will be delivered to whoever controls that local endpoint on the device. Exchanging that code then for an access token is easy since the client is public and the attacker know the PKCE verifier (if used).

    Yes but if a client supporting automatic registration were to host a metadata document with only https based redirect uris, how can an attacker impersonate the client and successfully obtain an authorization code?

    ‌

  19. Torsten Lodderstedt

    Yes but if a client supporting automatic registration were to host a metadata document with only https based redirect uris, how can an attacker impersonate the client and successful obtain an authorization code?

    Sure. That would be avoid this particular attack vector. It also means apps using custom schemes couldn’t use the relaxed behavior.

  20. John Bradley

    You could do the binding of the client to the entity statement later, but that really only works for the code flow.

    If we don’t sign upfront then the spec will become way more confusing trying to explain how public clients can prove that the entity statement belongs to the client.

    In general, the client needs to be able to do asymmetric signing to authenticate, so signing the registration is not a huge incremental burden.

    Apps wanting to prove they are part of a federation should generate local keys and have the wallet provider service generate the entity statements. The local keys can then be used to sign.

    ‌

  21. Michael Jones

    On the 25-Aug-22 Federation Editors' Call, we discussed that one of the main points of Federation is knowing that you’re communicating with others that are also members of the federation. If a party that is not the controller of the Entity Configuration can use it for Automatic Registration without proving control of it, we would lose that property. So we don’t think that relaxing the requirement makes sense for the OpenID Connect Federation use cases.

    Per the discussion points by Torsten and others, in other use cases of Automatic Registration, different decisions could be made, if it’s OK in those use cases to have clients that can’t be identified.

  23. Michael Jones

    The editor’s draft now includes this note about possibly using Automatic Registration with pure OAuth 2.0:

    Note that we anticipate that Automatic Registration could be employed for use cases beyond OpenID Connect Federation. If used with pure OAuth 2.0, for instance, Automatic Registration would occur during Authorization Requests.

    Perhaps we could also add a sentence to this paragraph saying that if it’s ok to have unauthenticated clients in a particular use case, then the requirement for signed requests could be relaxed. Would that finish resolving the issue for you, Tobias?

    (Note to self: The paragraph above landed in the wrong place and should be moved, when updated.)

  24. Michael Jones

    We discussed the proposal in the 2-Sep-22 Federation Editors' call, and people were OK with the suggestion above, assuming Tobias also agrees with it.

  28. Log in to comment
Assignee
Type
enhancement
Priority
major
Status
resolved
Component
Federation
Milestone
–
Version
–
Votes
0
Watchers
1
Jira: the preferred issue tracker for Bitbucket. Join the team!