Separate resource server implementation

[mkjpryor-stfc]

How come the separate resource server implementation uses a pre-generated access token (RESOURCE_SERVER_AUTH_TOKEN) to access the introspect endpoint?

I may be missing something, but rather than requiring a pre-generated access token with a long TTL, isn't this is an ideal use case for the client credentials flow?

[nyabwana]

where does the RESOURCE_SERVER_AUTH_TOKEN come from in this case? Is it just some random token you choose to create?

[mkjpryor-stfc]

@nyabwana:

Essentially, yes. The process I use is as follows:

1. Create a client-credentials application for my resource server.
2. Use curl (or some other client) to create a token using the client credentials.
3. Manually extend the token expiry in the Django admin to a large number of years.

What I think we should be doing is giving the credentials from (1) in the resource server settings, and django-oauth-toolkit should be doing (2). We wouldn't need to do (3) because the resource server would request a new token using its client credentials when the token expires.

[nyabwana]

@mkjpryor-stfc do the two applications share a database in this case? Which of the two applications stores the user credentials? Or do they both store the user details? I am really confused about how to achieve this.

[mkjpryor-stfc]

@nyabwana:

The authorisation server and the resource server are totally different machines with no shared database.

Only the authorisation server has the credentials and issues tokens. The resource server can check if a token is valid and the scopes it has by using the introspection endpoint. See https://github.com/evonove/django-oauth-toolkit/blob/master/docs/resource_server.rst.

[nyabwana]

@mkjpryor-stfc:
So how do you deal with protecting resources on the resource server? If the two were one, then my resources would have a foreign key to the user database but how about now that the databases are different? does it mean that we do away with the foreign keys for the resources?

[mkjpryor-stfc]

@nyabwana:

Your resource server has its own set of users with the same usernames as those on the authorisation server. django-oauth-toolkit handles the creation and authentication of these users for you based on interactions with the introspection endpoint.

If you delete a user and all their resources on the authorisation server, then their tokens will no longer be considered valid by the introspection endpoint, and so their resources on the resource server will become inaccessible. But they won't actually be deleted because, as you say, it is a different DB and there is no foreign key constraint to cascade. You would have to do that manually.

[mkjpryor-stfc]

@nyabwana:

P.S. In the nicest possible way, this thread wasn't meant to be explaining how this works... You can read the docs, RFCs and code for that. I was asking if it can be done better than it is now.

[prafulbagai]

@mkjpryor-stfc @nyabwana

How do I create a RESOURCE_SERVER_AUTH_TOKEN?

I've created an issue which I'm not able to understand. Following is the link of the github issue.

#529

Kindly provide your expertise.

[symptog]

@mkjpryor-stfc

Essentially, yes. The process I use is as follows:
Create a client-credentials application for my resource server.
Use curl (or some other client) to create a token using the client credentials.
Manually extend the token expiry in the Django admin to a large number of years.
What I think we should be doing is giving the credentials from (1) in the resource server settings, and > django-oauth-toolkit should be doing (2). We wouldn't need to do (3) because the resource server would > request a new token using its client credentials when the token expires.

where should django store this token?
Another option would be creating a management command for the AS

[mkjpryor-stfc]

@symptog:

There is nothing to store that isn't already stored. The deployment procedure would be:

1. Deploy Authorisation Server
2. Create client credentials app in Authorisation Server admin and note down client ID and secret
3. Deploy Resource Server with client ID and secret from (2) as settings

From then on, when the Resource Server needs to perform token introspection, it can use its client credentials to obtain a token to do so (or use an existing token if not expired).

This flow means that we do not need to manually create a token or manually extend the expiration date of that token, both of which feel like hacks to me...

[symptog]

Yeah, I know what you mean.
My problem with this approach is, that we need an additional request either to the AS or a cache.