php - oauth2 get access token via db by supplied client id/secret for trusted 3rd party client -


i'm using "lucadegasperi/oauth2-server-laravel".

i'm making api endpoint 3rd party trusted client , using client_credentials grant.

now thing access tokens tend expire, instead of giving 3rd party user access token, supply them client id/secret.

on side following when curl request...

select      a.id,             expire_time         oauth_clients c  left join   oauth_sessions s on s.client_id = c.id  left join   oauth_access_tokens on a.session_id = s.id        c.id = 'asfasasf'              , c.secret =  'asfasfasfasf'  order    s.id desc  limit       1; 

... above pretty checks if there access token , expire time relating client id/secret. i'd pretty generate new 1 if 1 didn't exist or if expired. couple lines down, curl on side endpoint after given access_token on side without them worrying doing it.

i've tested , works, kind of dodgy/bad do?

tldr;

  1. 3rd party client - goes /api/endpoint client id/secret
  2. my server side (checks access token in db relating client id/secret)
  3. generates if not exists or expired use ...
  4. 3rd party client endpoint api continues use db selected access token
  5. works

is bad flow?

all did take out step convenience.

a lot of people use oauth2 library or else wrote , of course wouldn't work because don't have standard oauth2 system anymore.

you've reused 1 token else uses client app , not convinced that's thing. tokens expiring security issues, if steals token, can invalidate , stop access or expires , that's it. of course don't have issue you're not passing tokens through.

this means you're breaking other oauth2 flows, many systems have refresh token, that's gone well. guess simplifies client's life quite bit can't have oauth2 system anymore, because well, don't.

the clients ones need deal tokens , it's job decide how store them , when things expire. wouldn't need worry it, since store client tokens on side.

one other thing consider shifted security concerns side. responsible clients security. if gets access database can impersonate clients forever more without or client knowing it. point of view having tokens in database bad idea , security flaw when client has no control on it.


Comments

Popular posts from this blog

mysql - Dreamhost PyCharm Django Python 3 Launching a Site -

java - Sending SMS with SMSLib and Web Services -

java - How to resolve The method toString() in the type Object is not applicable for the arguments (InputStream) -