juliuspc / openid-connect-php Goto Github PK

Maybe we should provide a better exception (see #7).

More details: jumbojett#243

This should be on a separate web page with more detailed examples on how to use the library.

Hi @JuliusPC
The maintainer of the upstream is OK to give write access to volunteers. Given the activity of your fork, I think it would make sense for you to join the team. Would you be interested? If so, I think you can just say a word there.

I am not sure the original author gets GH notifications, but I will write him an email then.

What do you think?

Almost anyone is using PHP 5 anymore. The package should upgrade to PHP 7.3 or 7.4 as minimum version, in order to take advantage of newest features.

This way, we can also remove the random_compat dependency

From the OIDC Discovery spec, section 4.3. OpenID Provider Configuration Validation:

If any of the validation procedures defined in this specification fail, any operations requiring the information that failed to correctly validate MUST be aborted and the information that failed to validate MUST NOT be used.

The issuer value returned MUST be identical to the Issuer URL that was directly used to retrieve the configuration information. This MUST also be identical to the iss Claim value in ID Tokens issued from this Issuer.

This library does not validate this in getWellKnownConfigValue().

PKCE is not enabled by default, you have to set $oidc->setCodeChallengeMethod('S256'); it by yourself.

Since the authentication flow with enabled PKCE even works with OpenID providers not capable of PKCE, it should be enabled by default. Since this may cause trouble with some providers, another option would be to only enable it in case it is present in the discovery document.

The methods requestClientCredentialsToken() and requestResourceOwnerToken() implement OAuth-only flows. Those are not supported by OpenID Connect, so maybe they should not be included in this library.

See: jumbojett#169

Although this library itself does not manage sessions, it may be useful to support handling the OpenID Connect part of handling sessions (validating the tokens and provide the data in an easy to consume way).

• Front-Channel Logout
• Back-Channel Logout

spec: OAuth 2.0 Authorization Server Issuer Identifier in Authorization Response

Why?
This helps to prevent so called mix up attacks. In such attack an client using multiple authorization servers can be confused about the AS that was used. Although this is still a draft, adding this feature should not mess anything up.

Duende IdentityServer already supports this.

See jumbojett#174 (comment)

It would be more practical if there were multiple, more specific exceptions with a defined inheritance hierarchy. This would be a solution to problems with missing metadata in the discovery document like the end_session_endpoint or introspectiong and revoking token.

PKCE does not work with confidential client requiring client secrets. If PKCE is enabled, client secrets are not sent.

This bug was introduced upstream.

RFC 7662 does not define a way to authenticate at the Authorization Server. Some real world examples:

• FusionAuth does not require authentication at all
• IdentityServer does not use the client secret for authentication. Instead, you have to configure an API secret for this.