search

thephpleague / oauth2-server

A spec compliant, secure by default PHP OAuth 2.0 Server
https://oauth2.thephpleague.com
MIT License
6.51k stars 1.12k forks source link

Internal same service authentication #1229

Closed Guichaguri closed 3 years ago

Guichaguri commented 3 years ago

I already have a service that has its own simple authentication system and user database. I'm implementing OAuth2 for Single Sign On for a few other external platforms.

Because of that, I'm revisiting and willing to rewrite the authentication mechanism.

The authentication on the external platforms seems pretty straight forward with OAuth2, but I'm puzzled on how should I implement the login sessions on the central server (which is also the one that serves OAuth2)

I see two solutions:

  1. Using a simple cookie-based session management system. This solution uses the OAuth2 only for external servers, while internally using a different authentication mechanism. It seems like using two different systems for the same purpose.
  2. Generating OAuth2 tokens by manually building a PSR-7 request, handling it with a custom grant and retrieving the access token. The same way it's done by Laravel Passport. Seems hacky but allows reusing the same authentication mechanism.

None of these solutions seem to solve the issue in an elegant way.

What is the best practice for this scenario? Is there a third solution that I'm not aware?

Guichaguri commented 3 years ago

I just found https://github.com/thephpleague/oauth2-server/issues/879 that leans towards the first solution, but since this central server is a SPA that also consumes the API, I still have to generate a token at some point.

What I mean is that I'm generating two distinct tokens for the exact same task, while also maintaining two systems for validating these distinct tokens, that's why I'm leaning towards the Laravel Passport solution.

Perhaps the AuthorizationServer class should have a generateAccessToken function that allows to manually create an access token from a client, scopes and user identifier?

Sephster commented 3 years ago

OAuth is a delegated authorisation service, not an authentication service. If you need authentication such as single sign on, you'd be better served looking at Open ID Connect.

If authorisation is what you require, I would recommend the internal users have a different login mechanism as you've outline in step 1.

Guichaguri commented 3 years ago

Thanks for the quick answer. I've read a little bit of the OpenID Connect spec, I can see how it helps with SSO, but it's not exactly what I'm aiming for.

I already have the authentication system in place, the only missing piece is the token generation/validation for the login form. I'll be using the first solution, creating a different type of token just for the login screen.

I still think exposing functions to manually create tokens without an http request would be a good idea, so extending from the authorization system would be way less hacky.