SSO for BE and ResourceAPI

[jack-robs]

Feature request

Stretch goal from Aaron S., SSO for BE and Resources API so we can create/update resources using logged in session rather than providing API key

Proposed solution

From Allen: if user is logged in an they have a valid JWT stored as cookie. This is already added to the auth header for any req's sent to backend.
From Aaron: could require some changes to resources API to do that
-> if requests also go to the Resources API, can just post key to /auth/token/verify

Potential alternative solutions

UK

Additional context

Next step planning after new website launch # @

[jack-robs]

@aaron-suarez @AllenAnthes

[pegasus-lynx]

@jack-robs Could you explain the issue a bit ?

[aaron-junot]

I can expand on this a little @pegasus-lynx

When we wrote the authentication for the Resources API, we did it more with systems users in mind because we weren't sure how all it would be used but we knew that we wanted to integrate with the OC Backend (BE) as well as Slackbot. So we decided to issue out API keys, which you obtain by making a request to resources.operationcode.org/api/v1/apikey with your OC credentials (username and password). Once you have your API key, you can send that with your request to Create or Update a resource.

As you might imagine, this isn't really a great workflow for the frontend to use to communicate with the Resources API. The user flow would go like this.

1. Log in to Operation Code
2. View the resources page, maybe search for a resource
3. Decide you want to update a resource. Now you have to enter your username/password again, and the front end has to store the API key which isn't really a great security practice because unlike a cookie, the API key is long lived.

So the idea is that if you're already logged into Operation Code, you have some type of session key or JWT anyway. This issue will be resolved when the Resources API can accept the session cookie from the OC backend as credentials for creating/updating resources.

There are a few ways to accomplish this, but I think that the most straightforward way is to take the cookie (or jwt or whatever we're using on the main site) and pass it to the create/update endpoints. The Resources API would then ask the backend "hey is this cookie valid?" and if the backend responds "yes" then perform the operation. If the backend doesn't respond yes, return a 401.

I'm not sure how session management works on the frontend/backend, so there might be work to get something that is accessible by the frontend to be able to pass it to the Resources API. @AllenAnthes can probably speak to that, or you can look at the code and see how it works.

If you have any questions about anything I said above or the work needed for the Resources API, I can explain it further, just ask.