oauth2通过db为受信任的第三方客户端提供的客户端ID / secret获取访问令牌

Question

I'm currently using "lucadegasperi/oauth2-server-laravel".

I'm making an api endpoint for a 3rd party trusted client and using the client_credentials grant.

now the thing is that access tokens tend to expire, so instead of giving the 3rd party user a access token, i would just supply them with the client id/secret.

on my side i would do the following when they do a curl request...

SELECT      a.id,
            expire_time

FROM        oauth_clients as c

left join   oauth_sessions as s on s.client_id = c.id

left join   oauth_access_tokens as a on a.session_id = s.id

where       c.id = 'asfasasf'

            and c.secret =  'asfasfasfasf'

order by    s.id desc

limit       1;

... The above pretty much checks if there is an access token and expire time relating to the client id/secret. I'd pretty much just generate a new one if one didn't exist or if it expired. Then a couple lines down, do a curl on my side to the endpoint they were after with the given access_token on my side without them worrying about doing it.

I've tested it and it works, but is this kind of dodgy/bad to do?

tldr;

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

Is that a bad flow?

Answer 1

All you did was take out a step for their convenience.

A lot of people would simply use an OAuth2 library they or someone else wrote and of course this wouldn't work because you don't have a standard OAuth2 system anymore.

You've effectively reused one token for everyone else who uses the client app and I am not convinced that's a good thing. Tokens expiring is for security issues, if someone steals a token, you can invalidate it and stop their access or it expires and that's it. Of course you don't have this issue as you're not actually passing tokens through.

This also means that you're now breaking other OAuth2 flows, many systems have a refresh token, that's gone as well. I guess it simplifies the client's life quite a bit but you can't say that you have an OAuth2 system anymore, because well, you don't.

The clients are the ones who need to deal with tokens and it's their job to decide how to store them and what to do when things expire. You wouldn't normally need to worry about it, but now you do since you actually store the client tokens on your side.

One other thing to consider is that you shifted the security concerns to your side. You are now responsible for the clients security. If someone gets access to your database then they can effectively impersonate all your clients forever more than likely without even you or the client knowing about it. From my point of view having tokens in a database is a bad idea and a security flaw especially when the client has no control over it.