Question

This is mainly a wording issue. But albeit a very important one, which can cause possible misinterpretations in big code bases being maintained by even bigger teams. Let’s say we have a very basic CRUD/RESTful app with an authentication system. In this case, the authenticated user trying to fulfill a data-changing request (POST/PUT) will be then identified by the server (authentication) and then it will be checked whether this identified user has the right to create/update the resource in question (authorization).

Now let’s say I’ll implement the Oauth protocol to at a later stage support some kind of web API solution. In this case, The user from Client App A will have to ask for authorization from the resource provider to do something.

So as of now, we have two valid notions of authorization inside the same app. At the application level it is not that big of a problem, since we can enclosed the two notions in a relevant namespace, but in the DB I have two valid candidates that cannot share the name authorizations.

As I’m not a big fan of namespacing table names, I’d like suggestions for possible renaming of one of them (or maybe some other wild solution you might have implemented).

Cheerio

Answer 1

How about oauthgrants or just prefix authorizations with more descriptive names?:
user_authorizations
and app_user_authorizations. This might violate your rule about namespacing, but would be much more descriptive.

user_authorizations or authorizations would just have what the user is allows to do within the system.

app_user_authorizations or oauthgrants would have which privileges the user has granted to third party applications via OAuth. It would store: user ID, OAuth 2.0 client ID, scope granted, refresh token (if exists), expiration (if exists). It may also have the access tokens depending on how you implement them (or they may be in another table or not stored because they’re cryptographically verifiable)