为PHP Web应用程序选择正确的OAuth2授权类型

Question

I'm building a very typical web app product. It will likely have corresponding mobile apps in the future. I'm building it from the ground up with a REST API, which is secured using OAuth2. I've got OAuth2 working, and I'm able to connect successfully using various grant types.

What I'm a little confused about is what grant types to use for the actual web app. Here's what I had in mind:

Public API access

Before a user logs into the web app, some API access is required for things like user registration and password resets. I was thinking of using the client_credientials grant type. A simple client id and secret validation in return for an access token.

However, it seems totally unnecessary to request an access to token for every single public request or even for each session. It seems to make more sense to just generate ONE access token that my web app will always use.

Yet, this seems to go against how OAuth is designed to work. For example, access tokens expire. What is the right way of doing this?

Private user API access

Next, for a user to login to the web app I was planning on using the password grant type (resource owner password credentials). This approach allows me to save the user_id with the access token—so I know which user is logged in. Further, by using scopes I can restrict access within the API.

I plan to save the access token within the PHP session. As long as the PHP session is active they will remain logged into the web app.

Is this an appropriate design for user login?

Answer 1

For Public API Access:

One method is to skip tokens all together and just use Basic HTTP Authentication for API access. You could accept Client Credentials for this, and limit what clients can do using client-specific scopes. Github offers HTTP Basic authentication using user credentials for all their API calls.

For Private user API Access:

This is an interesting question because it begins to breech the line between Authentication and Authorization . OAuth is used for Authorization , so logging in users becomes dicy. Session management, for example, is something not covered by the OAuth2.0 spec.

However, this is a common use of OAuth2.0 anyway. You can use the password grant type, or any other grant type for that matter, to obtain an access token. A major downside is they have to trust your application with their password (Not a big deal for your own app, but for 3rd parties not so much). Also, being logged in one place does not necessarily mean being logged in somewhere else (rather than SSO, you have "linked accounts", so the sessions are managed separately). One way around this is to ALWAYS send users to the oauth authorize endpoint, and if their session is active on the OAuth2.0 Provider side, reroute them back to the client app with an access token or authorization code. This way, if the session is active with the OAuth2.0 provider, the client can immediately log them in.