@Taluu

Here's the default value that I've defined, not sure about it:

->scalarNode('client_id')->defaultValue('12345678')->end()->scalarNode('client_secret')->defaultValue('12345678')->end()->scalarNode('authorization_url')->defaultValue('https://foo.com/authenticate')->end()->scalarNode('redirect_uri')->defaultValue('https://myapp.com/oauth')->end()->scalarNode('access_token_url')->defaultValue('https://foo.com/token')->end()

Any recommendation? 🤔

@Koc Configuration keys name fixed 🙂

My point was to remove these options from the default options. I don't see any case where something could be generic for these options (and merged into the options of the provider), and keep the "required" argument for them in the provider section.

Looks promising. Should be a sub component of the security one IMO (i.e. moved under theSecurity\ namespace and renamed tosecurity-oauth)

@chalasr Thanks for the feedback, yes, I totally agree with this idea, as OAuth is totally linked to the security.

Plus, it make no sense at all to use the defaultframework configuration node as the parent node of OAuth.

@Taluu Oh ok, sorry, I've missed the point the first time 😄

That's right, there's no case where an option can be "shared" with many providers, nice one 👍

@chalasr About the configuration, this is more a DX question but after thinking about it, here's my idea, what about moving this configuration:

framework:oauth:redirect_uri:'%env(REDIRECT_URI)%'# Can be useful in order to share the configuration?providers:github:type:'authorization_code'client_id:'%env(CLIENT_ID)%'client_secret:'%env(CLIENT_SECRET)%'authorization_url:'%env(API_AUTHORIZATION_URL)%'access_token_url:'%env(API_ACCESS_TOKEN_URL)%'google:type:'authorization_code'

Here:

security:providers:github_oauth:oauth:type:'authorization_code'client_id:'%env(CLIENT_ID)%'client_secret:'%env(CLIENT_SECRET)%'authorization_url:'%env(API_AUTHORIZATION_URL)%'access_token_url:'%env(API_ACCESS_TOKEN_URL)%'google_oauth:# ...firewalls:main:provider:github_oauth

I'm not a fan of the first one now as it sounds like the OAuth configuration is linked to the framework one (which is not now as it's been moved as a sub-component), plus, this make the configuration similar to the entity, id, ldap ones 🤔

Any suggestion?

Couldn't we promote@weaverryan's oauth2-client-bundle or HWIOAuthBundle as an official Symfony package instead of starting a new component from scratch?

I think that any official Symfony package should usesymfony/http-client to send http requests.

I think that any official Symfony package should usesymfony/http-client to send http requests.

Of course, but patching the two existing packages to use it is easy. Way easier than re-creating something from scratch.

@dunglas I don't know if it's easier to patch the existing packages (and hoping that nothing breaks) rather than adding this package, I've used Ryan's package and it's great, don't get me wrong, problem is, it's not "native" on Symfony and it force us to use an external package rather than using an "official" one which use the latest tools provided by Sf.

I could be wrong but (and if it's the case, just stop me) for me, it's important that Sf provide this kind of feature with an official package (which is not fragmented/splitted in sub-packages) that helps every developers to implement OAuth with a standard API and a "top-class" (not actually, I agree but I'm working on it 😄) integration on the framework.

I agree with@ajgarlag forHttpClient usages.

Actually, the package take 3-4 days to be created so it's not a big work for now, I see it as an experimentation and if it's clear that Sf doesn't have any gains on using it and prefer to promote@weaverryan's oauth2-client-bundle or HWIOAuthBundle as officials packages, it's okay for me 🙂

I don't know about@weaverryan's bundle, but for HWIO, it's a mess in there and something that is (almost) unmaintainable because of the providers which makes it really hard to use and implement a custom provider (hard-coded config).

Ryan's bundle is simpler, and more modern, but doesn't support OAuth 1.

@Guikingone I agree with the rationale of having more things, including an OAuth implementation, in thesymfony namespace. My point is why not simply renaming one of the existing battle-tested solutions (OAuth isn't easy) instead of starting from scratch? Switching from anything to HttpClient is straightforward, we've already done it for the MercureComponent, Panther, and the Symfony website ; and we're doing it for API Platform, it's just a matter of changing some method calls.

My point was that using the KNP client is simple, I agree with it but what if you need to add a new provider? And what about the maintainability?

On the current "component", it's simple, you have a default provider which is linked to the RFC requirements, you only need to instantiate it and configure the options (without creating a dedicated provider thanks to the Security configuration but you can if you need, the default classes are here to guide you and provide a RFC compliant implementation).
For now, the component doesn't rely on external component (except theHttpClient one, I agree), but KNP bundle depends on the PHPLeague library, which can change its API from one day to another (even if it's rare, it can happen), on Sf side and thanks to the BC promises, we can improve the component and maintain it without relying on external librairies (exceptHttpClient).

When it comes to maintainability, simple example, if you take a look athttps://github.com/knpuniversity/oauth2-client-bundle/blob/master/src/Client/Provider/GitlabClient.php andhttps://github.com/knpuniversity/oauth2-client-bundle/blob/master/src/Client/Provider/GoogleClient.php, where are the differences that requires you to create a dedicated provider?

For me, there's no reason to have dedicated provider as you don't override the arguments, don't change the$token class and so on.

The component in this PR can get rid of this code duplication and improve the DX as the don't need to use multiples classes to do the same things.

As always, I can get wrong and if it's the case, just stop me 🙂

When it comes to maintainability, simple example, if you take a look athttps://github.com/knpuniversity/oauth2-client-bundle/blob/master/src/Client/Provider/GitlabClient.php andhttps://github.com/knpuniversity/oauth2-client-bundle/blob/master/src/Client/Provider/GoogleClient.php, where are the differences that requires you to create a dedicated provider?

@return GitlabResourceOwner vs@return GoogleUser. They override the method to override the phpdoc with a specific child class to give better autocompletion when you work specifically with one provider.
And they do that because of their own API wrapping the PHPLeague providers. the OAuth2 implementation is actually in PHPLeague, where specific providers are implemented (either in core or third-party) to preconfigure options for ease of use (similar to what we did for mailer, where we have some pre-configured Smtp transports).

KNP bundle depends on the PHPLeague library, which can change its API from one day to another (even if it's rare, it can happen)

Well, PHPLeague also follows semver, so that would still not break your app. Symfony's BC policy is "we follow semver" + "we always provide deprecation warnings before doing BC breaks" (+ a time-based release schedule so that you know when you can expect a major version, but that's not necessary for such good experience, especially for smaller packages like the ones from PHPLeague which may not have a need for major versions as often)

@Guikingone I think this should all be named such that it's clearly part of OAuth 2.0 as opposed to OAuth 1.0 / 1.0a

@kralos Hey 👋

Sorry for the delay, yes, it could be a good idea, maybe naming it asOAuth2Client andOAuth2Server can be a solution? 🤔

@Guikingone JWT's are not part of OAuth2's specification, they are supported via anOAuth2 Extensionhttps://tools.ietf.org/html/rfc7519#page-19

[Opinion] Do you think we should solve core vanilla OAuth2, then add Extensions as optional pluggable add ons (Security\Core\Authentication\Provider\AuthenticationProviderInterface +Security\Http\Firewall\ListenerInterface etc)?

Developers might want to plug their ownOAuth2 Extensions into the Symfony core OAuth2 implementation.

If you start implementing extensions in Symfony Core, people might expect you to implement all extensions.

Hi@kralos 👋

Yes, in fact, I was experimenting on this one, the core idea is to solve core OAuth2 specifications thenif developers wants to add extensions, providing a set of interfaces (like contracts?) to do it.

That's more or less the idea behindProviderInterface for now 🙂

As long as you implement this interface, you can add every provider that you need.

For now, I'm focusing on resolving core issues when it comes to authorization attacks as described here:

• 6819
• 7009
• 7662

I was also thinking about implementing Dynamic Client registration as described in7591 but I don't know if it's really needed for now (as the Client is almost ready for usage).

When can we start using it ?

When can we start using it?

Hi@manu-sparheld, for now, the client is available and open for alpha testing using the repository, I'm currently working on the security aspect of the component and polishing the DX, feel free to give feedback 🙂

This looks very promising. What is the progress? =)@Guikingone

Hi @j-mywheels,

Thanks for the interest, the component is almost done for theOAuth2Client part of it, theOAuth2Server is for now "paused" and moved to a later release on my side.

I'm currently working on the Symfony integration (mostly Security component and DIC usages) 🙂

And given we are already past the feature freeze (way past it), this component won't be part of 4.4 and 5.0. It will have to wait for 5.1

Also a couple questions, will the AccessToken, RefreshToken, Client, Scope.. etc. be linked to Doctrine entities?

Would it be possible to create extension grants (https://tools.ietf.org/html/rfc6749#section-4.5)? it might be useful to see how we can implement two factor authentication in the early stage of this component (using the extension grant for example)?

Hi@jamalo 👋

For now, the OAuth2Client isn't linked to Doctrine, the "bridge" with the framework can bring a relation due to security internal logic (mostly when it comes to providers) but the core classes aren't linked, the only "relations" are HttpClient and OptionsResolver.

When it comes to Extension Grant, for now, it's not planned as the main requirements are related to the endpoint that you're using (SAML, etc) but it can easily added thanks toGenericProvider (which is the parent provider) 🙂

Hi@jamalo

For now, the OAuth2Client isn't linked to Doctrine, the "bridge" with the framework can bring a relation due to security internal logic (mostly when it comes to providers) but the core classes aren't linked, the only "relations" are HttpClient and OptionsResolver.

When it comes to Extension Grant, for now, it's not planned as the main requirements are related to the endpoint that you're using (SAML, etc) but it can easily added thanks toGenericProvider (which is the parent provider)

Hopefully this will makeFOSOAuthServerBundle past time. Good luck@Guikingone

I have not looked at the code. This is interesting as OAuth is everywhere nowadays.

Before going further, I'd like to get thoughts from@weaverryan (as it maintains a similar bundle) and@wouterj as he is actively working on modernizing the Symfony security system (and we talked about OAuth support recently).

I've never used OAuth, everything below this paragraph is based on a few google searches. I apologize if it doesn't make any sense, in that case feel free to ignore it.

I'm a bit on the same track as@dunglas in the comments above.

I feel like OAuth consists of 2 completely saturated PHP communities: OAuth and Http clients. I don't think it makes sense to oversaturate it by creating yet another OAuth component. Apart from that, this also means someone has to maintain the Symfony OAuth component and keep it up to date with the specs, etc.

From what I read here, it seems like the lack of HTTP Client support is the biggest "issue" with the League OAuth package (which is used by the Knp bundle). Can't we discuss with the PHP League maintainers to find out if they are open for building against a standard interface (whichthey already did before 1.0)? Symfony's HTTP Client and Guzzle are implementing tons of interopability interfaces, it must be possible to find one that can be used imho.

Also, PRs likesymfonycorp/connect#95 makes me think there might not be need for a full-blown OAuth component and a couple abstract authenticators might be enough of a help? If someone wants multiple social logins, they can use the popular OAuth bundles already.

I agree with@wouterj that having support for HttpClient in League OAuth package would be much better (https://github.com/thephpleague/oauth2-client).