oauth2-server

oauth2-server copied to clipboard

Is there any example MySQL schema implementation for v6?

Thanks in advance.

@alessandroraffa not yet, but thanks for the suggestion. We'll keep this issue open until we have something.

I'm currently working on Yii2 integration and have a DB migration for it (which is not finished though). Would like to hear you thoughts on this.

The MySQL schema can looks something like this, if I haven't forgotten anything. In fact, there is nothing extraordinary here. Usually each application/framework impose its own limitations.

@sergeyklay So according to your schema:

• clients have scopes and grants
• users can also have scopes and grants

Im a bit confused why would user accounts need grants and scopes directly without clients registered?

@loganto I believe it depends on the type of grant you're doing which drives where the scopes get stored. In the Client Credentials grant, for example, the user scope table is unnecessary as there are no "users" in that grant.

---

Something I'm confused by is id's versus identifiers. In all of the interfaces only the identifier is used, never the id. AccessTokens are where this is really odd. In the access_tokens table by @sergeyklay, there is a client_id column which is an BIGINT UNSIGNED. But the client interfaces only required the identifier. If we look at the clients table there are two columns, id and identifier — the former is a BIGINT UNSIGNED and the latter is VARCHAR(128).

According to this, it would seem that the client_id is the id column. But it can't be as it's not even the right type to store it. Having both the id and identifier columns seem redundant, and the latter should so have a UNIQUE constraint.

I may be wrong, but I believe the clients table should only have an identifier (or id, whatever you want to name it) column that is a VARCHAR(128) for storing the long identifier. The access_token table's client_id should then match this column type.

Storing the id in that column seems nice but the interfaces suggest that it's the long identifier and not id that's being stored. I could be wrong. It's possible the mix up of the two terms just lends this whole setup to be confusing.