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

Are changes to OIDC request protocol in section 10 required

Issue #2095 resolved
Stefan Santesson created an issue

Section 10 alters requirements on the request protocol relative to OIDC core.

  • Passing the structured request parameter MUST be signed JWT
  • If the trust_chain request parameter and trust_chain header is present. The OP is required to process them and compare them. This means that an OP MUST implement this check, even if they don’t use this (e.g. they rely on a resolve endpoint)

Isn’t the basic Idea that any set of OIDC and OAuth services should be able to use OpenID federation just as source of peer metadata, keys and Trust Marks, without changing the way they use OIDC or OAuth.

Are services that implements OIDC according to OIDC core not welcome in the federation unless they change their implementation of OIDC and OAuth?

I have problems understanding why the federation specification chooses to alter requirements on the core protocol. All data is resolvable from the federation by knowing the EnityID of the peer and trusting critical federation keys.

Comments (13)

  1. Giuseppe De Marco

    the trust_chain JWS header parameter is not mandatory, it just extends OAuth 2.0 and/or OpenID Connect Core 1.0, as PKCE does and many other parameters that improve the security of the solution

    Are services that implements OIDC according to OIDC core not welcome in the federation unless they change their implementation of OIDC and OAuth?

    I would not say not welcome, I would say what is or not the implementation profile that may require some kind of trust marks or the requirement of the static trust chain in the request

  2. Giuseppe De Marco

    OpenID Federation doesn’t require the OIDC Core should change its implementation, but, anyway, many impl profile, like iGov or FAPI does this and for the security of the solution; it seems to me that these “improvements” are really welcome by implementers, when the security is in the list of the requirements.

    If you look to openid federation for improving the security of an infrastructure of trust I would suggest to follow its recommendation, that in comparison with other profiles like iGov, has the minor impacts ever on the oidc core 1.0 specs, because it doesn’t change the protocol specific flow but just extends them optionally. It’s written in the specs.

    Do you use PKCE in your implementation?
    I would bet: yes.

    Does impact PKCE on the OpenID Core 1.0 specs?
    I say: yes.

    Why you have decided to extend OpenID Core 1.0 with an impl profile?
    I’d say: because you need it for the security of the solution.

    Please use Federation in the same way, If you look for something robust and scalable, that give the freedom to the participants to change their metadata and reducing the bureoucratic costs, you’re in the right place!

  4. Stefan Santesson reporter

    But why is it then still allowed to send all request parameters unsigned by providing them as direct parameters and not as a structured “request” parameter?

  5. Stefan Santesson reporter

    Michael,

    In the very specification you cited section 6 (Passing Request Parameters as JWTs) sates:

    request

    OPTIONAL. This parameter enables OpenID Connect requests to be passed in a single, self-contained parameter and to be optionally signed and/or encrypted.

    ‌

  6. Michael Jones

    I was responding to your statement “Passing the structured request parameter MUST be signed JWT“. My point was that structured request parameters are always signed JWTs, so this isn’t a change.

  8. Stefan Santesson reporter

    Mike,

    My comment refers to the requirements in section 10.1.1 (Authentication request). This section and the following section 10.1.1.1 (Using a Request Object) all refers to an authentication request to the OP.

    This is described in OIDC core section 6.1.

    Section 6.1 in OIDC core does not require JWT in the request object to be signed:

    The Request Object MAY be signed or unsigned (plaintext). When it is plaintext, this is indicated by use of the none algorithm [JWA] in the JOSE Header.

    ‌

    Now reading about the OP metadata parameter “request_authentication_methods_supported” makes this somewhat more clear, but not completely.

    This seems to be the place where I can learn about the requirement placed on the OP to verify that the request is sent by the client match the registered key of the client.

    In 10.1.1.1.2 the text appears to make this optional:

    Once the OP has the RP's metadata, it can verify that the client was actually the one sending the Authentication Request by verifying the signature of the Request Object using the key material the client published through its metadata (underneath metadata/openid_relying_party).

    The wording is can and not must.

    This leads to some questions and thoughts:

    The normal OIDC way to verify a client registered key is at the token endpoint (e.g. using “private_key_jwt”). A rouge request is further stopped by registering valid return URL:s for the requesting client when returning the authorization code.

    If this is good enough for some OIDC deployments using dynamic client registration, or direct manual registration, why isn’t it good enough when the source of the metadata is retrieved from a federation?

    My understand is that the federation is just another way to obtain trusted and verified metadata. Why does that require all services to apply a more secure version of OIDC than they currently do?

    I can understand this if there is a threat caused by using OpenID federation, that must be mitigated by verification of the signed request JWT. I don’t believe that threat is explained. Or is it?

    Finally. If the verification of the request is mandatory, then why is request_authentication_methods_supported Optional?

    Shouldn’t there then at least be a default value, like default “request_object”?

    I like security and I like signed JWT in requests, even encrypted ones. But isn’t this a decision by the federation and expressed in policy based on their risk assessment?

    ‌

    I would personally like more of a recommendation, but allow implementations of OIDC to make their own risk assessment and let OIDC core define the valid options.

    If you disagree, then feel free to close this issue. I just wanted to draw your attention to this, in case some of this was not intended.

  9. Michael Jones

    You’re right that the “can” is sloppy. We should either make this a MUST or write Security Considerations saying what can go wrong if you don’t verify the identity of the client.

    With respect to your comment about client authentication normally happening at the Token Endpoint, that’s true for generic OAuth 2., but we intentionally require authenticating the client with the authorization request when using Automatic Registration. A whole lot happens at registration time that you want to not have happen if it isn’t a legitimate client. This is another point we should make sure that we’re clear on in the spec - both the “what” and the “why” of it.

    Thanks again for your careful reading of the spec. There’s no substitute for feedback from developers and deployers!

  10. Stefan Santesson reporter

    Mike,

    You’re the grandfather of OIDC compared to me. I’ve been stuck in the SAML world for ages. So I really trust your judgement on this. But still allow me some followup questions.

    You say that using authentication at the Token Endpoint is true for generic OAuth, but isn’t that also a mechanism commonly relied upon in OIDC?

    Even the dynamic registration specification allows unsigned requests. I.E

    request_object_signing_alg

    OPTIONAL. JWS [JWS] alg algorithm [JWA] that MUST be used for signing Request Objects sent to the OP. All Request Objects from this Client MUST be rejected, if not signed with this algorithm. Request Objects are described in Section 6.1 of OpenID Connect Core 1.0 [OpenID.Core]. This algorithm MUST be used both when the Request Object is passed by value (using the request parameter) and when it is passed by reference (using the request_uri parameter). Servers SHOULD support RS256. The value none MAY be used. The default, if omitted, is that any algorithm supported by the OP and the RP MAY be used.

    Noting: The value none MAY be used.

    ‌

    I would love a Security Considerations section explaining the threats here.

    My assumption when using OpenID federation is that the data obtained from entities (in particular their EntiityID, their keys and return URL:s) can be trusted. Because if a rouge entity can register the wrong keys for another entity, then how does validating the signing key (supplied by the rouge entity) in the request save me?

    If I have the right combination of entity ID and keys from metadata, then I believe I would stop unauthorised authentication also at the token endpoint. No access token or ID token would be issued.

    If there is an explicit threat with using the federation automatic registration, that can be exploited when using the federation as source of trusted metadata relative to other forms of registration sources, then that is very important information to implementers. I would hate to miss that.

    Does this also mean that you are not allowed to pass request parameters using the OAuth syntax in plaintext. I.E that you MUST use the “request” parameter with a signed JWT?

    Is the following allowed:

    GET /authorize?
    scope=openid
    &acr_values=loa3
    &response_type=code
    &redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Foidc-rp-bid%2Freturn
    &state=cded731a5daae92a
    &code_challenge_method=S256
    &nonce=5fa73cff2c5326fb
    &client_id=entity_id_url
    &code_challenge=iSl1eu_xF39NE36Jzeqhe32I1AvcuoIj1BpAlBgvNYM

    If this is not allowed, I don’t think it is stated clearly enough.

    I think most implementers would read the current text to say that IF you pass parameters as a “request” parameter, then the JWT MUST be signed.

    ‌

  11. Vladimir Dzhuvinov

    My comment refers to the requirements in section 10.1.1 (Authentication request).

    This section describes the OpenID authentication request with the so called “automatic client registration”.

    OpenID relying parties (and generic OAuth 2.0 clients) that utilise this client registration method can, by the nature of the method, only establish a public key based client authentication with the OpenID provider - private_key_jwt, or tls_client_auth or self_signed_tls_client_auth if using mTLS (RFC 8705). An RP that uses public key based auth is expected to be able to sign things. If the RP is able to sign, then it makes sense to sign its authentication requests and gain the following benefits:

    1. Within the OAuth code flow, it authenticates the RP on the first call to the OpenID provider.
    2. It guarantees that the end-user will be subjected to any authentication and / or consent steps at the OpenID provider in response to a legitimate request. With an unsigned OpenID authentication request, the request isn’t authenticated, which means it can be made by a malicious party. The malicious party will not be able to obtain an ID or access token, because it’s not in possession of the RP’s legitimate private key. However, there may still be security, cost and other implications with unauthenticated requests. That’s why profiles like FAPI mandate a signed request or request_uri (or PAR).

    ‌

    ‌

    ‌

    ‌

    ‌

  13. Michael Jones

    The client verification requirement for Automatic Registration has been strengthened as a result of this issue.

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