Separating resource & authorisation server roles

[AP-Hunt]

Hi Laravel Passport contributors,

I'm glad to see Laravel now has an official, integrated oauth 2 implementation. However, I notice that right now there is no way to separate the resource server and authorisation roles (as defined in the oauth 2 spec). That is to say, Passport cannot be setup purely to be a resource server which accepts and validates JWTs against a known authorisation sever's public key/certificate*.

Is this something that is envisioned in any roadmap of the package? (I don't see one documented anywhere, so perhaps those plans are in somebody's head?) I would be interested in contributing to the splitting of those roles, because I see this as a shortcoming of many other like packages.

Regards,
Andy

*Unless I'm very much mistaken. If somebody could point me in the right direction, that would be appreciated

[themsaid]

I'm interested to know why is it useful to make this type of separation? Just Curious :)

[lukepolo]

Its useful when you have a large resources with a lot of endpoints that need securing so you can have a standalone authorize server. This would allow us to setup multiple micro services, and still use the same authorization server.

Assets :
Auth Server A
Auth Server B

Service A - Photo Service
Service B - Video Service
Service C - Processing Service

Scenario 1 - Security :

Service A / B / C , ask for a token authorized by Resource A. And therefore do not require us to send our password to 3 different services just one. Also if resource A is compromised , we can then reject all tokens from that resource server and use Resource Server B.

Scenario 2 - Temporary Access to resources :

Service B wants access to Service C to process some videos . We now can just temporarily give Service B access to the users resources on C without the users name and password.

[AP-Hunt]

@lukepolo , could you clarify what you mean by "Auth Resource Server", please? Do you mean a server acting as both the authorisation and resource server roles? I think I understand your scenarios, but better safe than sorry :)

A third scenario could be when communicating across business boundaries. Perhaps the business has bought in some fancy new SSO kit that implements OAuth 2 (and maybe OpenId connect), and now they want to be able to log in to their purchase order system with it. In this case, the PO system isn't creating the token, but simply accepting and verifying it.

In some cases, it's even feasible that the service receiving the tokens doesn't need or want any more information than what's in the token. Continuing with the PO system example, here are a couple of scenarios where information in the token would be sufficient

• Access control. The scopes contained in the token can be used to drive access control. For example, if a token only contains the department_a scope, then the user can't view department B's data, or any of the pages specific to department B
• Auditing. The PO might only need to know who the user is in order to do something like audit who's been looking at different orders. In this case, a user id claim in the token would be sufficient.

[lukepolo]

Sorry, It should have just been Auth Server . Its only role would to distribute access tokens.

[taftse]

@lukepolo you mean something similar to office365 where you sign in to login.microsoftonline.com and then get redirected to one of the included (separate) services such as Outlook, SharePoint, OneDrive etc

[lukepolo]

@taftse yes, as the login.microsoftonline.com is their auth server while the others are the resources.

[AP-Hunt]

As far as I see it, there are a (broadly) a handful of scenarios for different setups of OAuth 2 resource and authorisation servers

1. Both the resource and authorisation servers live inside the same application, sharing a data store and a code base. This is probably the most common.
2. The resource and authorisation server are separate applications, but share a data store. They may also share some data access logic
3. The servers live in different applications and don't share a data store or a code base. The resource server, however, can make requests (perhaps using a client credential grant) for more information about the user.
4. The servers live in different applications, don't share a data store or a code base and the resource server cannot (or does not need to) ask the authorisation server for more information.

Scenarios 1 and 2 are, I would hazard a guess, the most common overall and the most common in small implementations.

Scenarios 3 and 4 are probably more common amongst larger installations and public api's; see Google, Facebook etc.

I'd be interested to know @taylorotwell and other contributors' visions for which of these scenarios they feel Passport should be targeting now and which are in mind for further down the road.

[jeffsrepoaccount]

For what it's worth, I started trying to get a complete separation implemented using the old lucadegasperi/oauth2-server-laravel. You can see what I got done before I got distracted in this repo.

What I wound up getting to work was being able to have completely separate databases, with the only anchor between the two being a user model on the resource server with its $connection property pointing to the authorization server's connection. This means that the resource server would still have to be aware of the access credentials to the authorization server's datastore, but I was really just mostly interested at the time in trying to get the user and oauth tables out of my resource database.

The good news is that lucadegasperi/oauth2-server-laravel and laravel/passport share a common upstream dependency in league/oauth2-server, so this approach may work with passport, also.

[taftse]

I think I have been able to achieve what you were looking to do

1. I have a Authentication service as one app with passport completely installed.
2. I have a separate Resource service (API) with just the passport API Auth Middleware installed to validate Auth tokens for each request.
3. and then a separate front-end app which uses socialite to authenticate to the Authentication service and request an Auth token which is then used to consume the resource servers API endpoint.

I'm planning on doing a full write-up on how I accomplished this when i have a bit of time

[alexjose]

It would be great to have library for resource server just to validate the JWT token.

[gandra]

I am also wondering is it possible to use laravel passport as pure oauth/SSO server ?
I mean the following:

1. I have 3 different project in different code bases
2. I want to introduce SSO ad fourth project/codebase

Could I achieve it using laravel passport?

My question is overlaping with @AndyBursh post but this is what I am very interested in at the moment.

[Evertt]

I'm planning on doing a full write-up on how I accomplished this when i have a bit of time

@taftse did you end up making that write-up somewhere? I'm looking for exactly what you're talking about and it's becoming quite important. So I'd love to know how you did it exactly.

[aliasdoc]

Hi, you can do that with introspect endpoint.

[kutubjt]

I know this issue has been closed long back. But for anyone running into this requirement, here is how you solve it. Laravel Passport stores the public and private keys here:

storage/oauth-private.key
storage/oauth-public.key 

You just need to copy the oauth-public.key from authorization server to your resource servers and use one of the popular PHP JWT library to validate incoming JWT tokens (Bearer tokens included in Authorization header) using the oauth-public.key as the public key. Now that the public key is available locally on the resource server itself, there is no need to make a round trip to the Authorization server for validation.

[angedid]

Passport has been design to implement Oauth2 specification. 4 entities are involve in the protocol. The user, Client Application, Autorization server and Resource server.
1- Resource Server does not need Passport. All what it need is to ask to Autorization server if the token in a given request header is valid. If the token is valid the request is executed. If not the it throws 403 execption.
2- The authorization server is where Passport have to be configure to authenticate user an generate token containing their access. The token have all information on the user: Authentication and access(role and scope). Links in resource server are protechted by scope.

3- When a user authenticate it self trought clien application (with client information on authorization server) a token is issue to the client application to be use on all next request to resource server.

[diego-lipinski-de-castro]

I know this issue has been closed long back. But for anyone running into this requirement, here is how you solve it. Laravel Passport stores the public and private keys here:

storage/oauth-private.key
storage/oauth-public.key 

You just need to copy the oauth-public.key from authorization server to your resource servers and use one of the popular PHP JWT library to validate incoming JWT tokens (Bearer tokens included in Authorization header) using the oauth-public.key as the public key. Now that the public key is available locally on the resource server itself, there is no need to make a round trip to the Authorization server for validation.

Example? I tested with tymondesigns/jwt-auth and could get the token to verify correctly