OAuth2 authentication provider in Neos - is there a stable base to extend?

Using Neos & Flow Flow App Development
1

I tinkered a bit with OAuth2 authentication lately and used https://github.com/Flowpack/Flowpack.OAuth2.Client as a base (thank your for that).
I built a first draft for Instagram Authentication on top of that package, while refining it I encountered 3 key problems however:

*) Using the package as base for my own authentication has the side effect of bringing a full fledged facebook configuration with it which I don’t need (but which prevents me from using “allTokens” as strategy - unless I introduce a requestPattern to solve that)
*) I expect people will have a very hard time using this package as base due to lack of documentation - in my case afoeder kindly pasted me some details and ChristianM ( :tophat: ) helped me out on some issues
*) There are multiple packages out atm (Christians Bootstrap Package https://github.com/neos/twitter-bootstrap, the GA plugin, etc.) and they all seem to have a different way of handling the authentication

The easiest way to continue for me would be putting the classes I need from the Flowpack.OAuth2 package into my own (interfaces, abstract), but package wise this would be a bad approach - I strongly agree with Dmitri on the fact that “Packages should serve a single purpose” in this case I could imagine a “Flowpack.OAuth2.Client” package that serves the single purpose of “Providing a base for implementing a custom OAuth2 authentication process” (which it actually could do very well with some tweaks)

Long story short: Is there something on the roadmap on how this should be handled in the future and what is the suggestion of the Neos team on how to continue.

2

Hi @floweiss1

I used the package

as base for a generic Oauth authentification that looks like this

I relies on the implementation of the PHP Leaguge packages, but gives me the chance of creating new OAuth authentication provider by passing a array to the authentication providers configuration given the keys that the PHP League requires to do “the talking”.

          'FacebookProvider':
            provider: Vendor\Application\Security\Authentication\Oauth\Provider\FacebookProvider
            providerOptions:
              implementationClassName: League\OAuth2\Client\Provider\Facebook
              implementationClassOptions:
                clientId: 'CLIENT_ID'
                clientSecret: 'SECRET_KEY'
                graphApiVersion: 'v2.8'
          'LinkedinProvider':
            provider: Vendor\Application\Security\Authentication\Oauth\Provider\LinkedinProvider
            providerOptions:
              implementationClassName: League\OAuth2\Client\Provider\Linkedin
              implementationClassOptions:
                clientId: 'CLIENT_ID'
                clientSecret: 'SECRET_LEY'

and as you can see, the FacebookProvider class doesn’t do anything else than pass a token class and a name of the object managing response from the specific provider.

I hope that it can help you or others :slight_smile:

2 Likes