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

[5.x] Adding basic authentication by default on signed routes #684

Merged
merged 1 commit into from
Feb 1, 2024

Conversation

moufmouf
Copy link
Contributor

@moufmouf moufmouf commented Feb 1, 2024

According to RFC-6749 clients can choose from a number of authentication methods to authenticate with the authorization server.

Section 2.3.1 states that clients can put the credentials either as a Basic authorization header or passing the credentials in the body of the POST.

Right now, the default method for Socialite (in AbstractProvider) is to pass the credentials in the body of the POST.

However, the spec states this:

Including the client credentials in the request-body using the two parameters is NOT RECOMMENDED and SHOULD be limited to clients unable
to directly utilize the HTTP Basic authentication scheme (or other
password-based HTTP authentication schemes).

So Socialite passes the credentials using the "non recommended" way.

Furthermore, this way of passing the credentials in NOT supported by all servers. However, the Basic authentication method is mandated to be compulsory per the spec:

The authorization server MUST support the HTTP Basic
authentication scheme for authenticating clients that were issued a
client password.

As a result, a number of providers need to manually add the Basic authentication as you can see from a simple Github search on the "Providers" Github repository:

https://github.com/search?q=repo%3ASocialiteProviders%2FProviders%20Basic&type=code

It would be better to use by default the only authentication scheme that we know (for sure) is supported by all servers.

This commit adds Basic authentication header to the requests created by the AbstractProvider.

It does not remove the parameters in the body in order to limit breaking changes.

@driesvints driesvints changed the title Adding basic authentication by default on signed routes [5.x] Adding basic authentication by default on signed routes Feb 1, 2024
@driesvints
Copy link
Member

Could you fix the tests?

@driesvints driesvints marked this pull request as draft February 1, 2024 15:38
According to [RFC-6749](https://datatracker.ietf.org/doc/html/rfc6749#section-2.3.1) clients can choose from a number of authentication methods
to authenticate with the authorization server.

Section 2.3.1 states that clients can put the credentials either as a Basic authorization header or passing the credentials in the body of the POST.

Right now, the default method for Socialite (in AbstractProvider) is to pass the credentials in the body of the POST.

However, the spec states this:

> Including the client credentials in the request-body using the two parameters is NOT RECOMMENDED and SHOULD be limited to clients unable
> to directly utilize the HTTP Basic authentication scheme (or other
> password-based HTTP authentication schemes).

So Socialite passes the credentials using the "non recommended" way.

Furthermore, this way of passing the credentials in NOT supported by all servers. However, the Basic authentication method is mandated to be
compulsory per the spec:

> The authorization server MUST support the HTTP Basic
> authentication scheme for authenticating clients that were issued a
> client password.

This commit adds Basic authentication header to the requests created by the `AbstractProvider`.
@moufmouf
Copy link
Contributor Author

moufmouf commented Feb 1, 2024

Could you fix the tests?

Done!

@moufmouf moufmouf marked this pull request as ready for review February 1, 2024 17:21
@taylorotwell taylorotwell merged commit 05af22c into laravel:5.x Feb 1, 2024
20 checks passed
@Flightfreak
Copy link

Not disputing it being part of the RFC, but this is a breaking change. Did this belong in a minor?

driesvints added a commit that referenced this pull request Feb 16, 2024
driesvints added a commit that referenced this pull request Feb 16, 2024
@driesvints
Copy link
Member

@moufmouf I've reverted this again because it seems it's too much of a breaking change for third party providers. We can reconsider for the next major release maybe.

@Flightfreak reverted

@moufmouf
Copy link
Contributor Author

No problem 👍
Next major is fine.

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

Successfully merging this pull request may close these issues.

None yet

4 participants