rest - Choosing the right OAuth2 grant type for PHP web app -

i'm building typical web app product. have corresponding mobile apps in future. i'm building ground rest api, secured using oauth2. i've got oauth2 working, , i'm able connect using various grant types.

what i'm little confused grant types use actual web app. here's had in mind:

public api access

before user logs web app, api access required things user registration , password resets. thinking of using client_credientials grant type. simple client id , secret validation in return access token.

however, seems totally unnecessary request access token every single public request or each session. seems make more sense generate 1 access token web app use.

yet, seems go against how oauth designed work. example, access tokens expire. right way of doing this?

private user api access

next, user login web app planning on using password grant type (resource owner password credentials). approach allows me save user_id access token—so know user logged in. further, using scopes can restrict access within api.

i plan save access token within php session. long php session active remain logged web app.

is appropriate design user login?

for public api access:

one method skip tokens , use basic http authentication api access. accept client credentials this, , limit clients can using client-specific scopes. github offers http basic authentication using user credentials api calls.

for private user api access:

this interesting question because begins breech line between authentication , authorization. oauth used authorization, logging in users becomes dicy. session management, example, not covered oauth2.0 spec.

however, common use of oauth2.0 anyway. can use password grant type, or other grant type matter, obtain access token. major downside have trust application password (not big deal own app, 3rd parties not much). also, being logged in 1 place not mean being logged in somewhere else (rather sso, have "linked accounts", sessions managed separately). 1 way around send users oauth authorize endpoint, , if session active on oauth2.0 provider side, reroute them client app access token or authorization code. way, if session active oauth2.0 provider, client can log them in.