Client_ID

[lucasmichot]

It feels a bit strange to get a client ID as the primary key of oauth_clients @taylorotwell
Would it not make sense to provide a uuid field for that ?

[jbrooksuk]

I was wondering the same, UUID, or at least a random string of a given length seems more natural.

[lucadegasperi]

Having an auto incrementing key as the client id could expose some unwanted info about the system (like how many clients are registered in the app) the easiest solution would be to hash the id when it's exposed to the outside world. Something like what the https://github.com/vinkla/laravel-hashids package does.

Agreed, the spec tells it should be a string (VSCHAR) https://tools.ietf.org/html/rfc6749#page-71 https://tools.ietf.org/html/rfc6749#section-2.2

[lucasmichot]

I feel like using a random string in a new indexed key field would be a starting point for this issue...
Any thought on that @taylorotwell ?

Hi, I made this #49 PR. I use md5 to hash userId and name. Is it enough?

[jbrooksuk]

md5 is slow, I agree with @lucasmichot, a random string should be enough.

@jbrooksuk, what about unique client_id?

[taylorotwell]

It's fine that it's auto incrementing. Client IDs are public values and there is not a security risk to exposing one. A UUID4 value is not sequential and is not nearly as efficient to index in the database as an auto incrementing value.

[taylorotwell]

That being said, I don't really care either way. It would be a major version break to switch to UUIDs now though.

[taylorotwell]

Some are not understanding that Client IDs are public on Twitter, so I'll post an example here. If you are an OAuth server supporting authorization_code grants your consumers have to include their client IDs directly in the URL when they redirect to your application. For example, I just tried to login to GitLab using GitHub OAuth and could easily just grab GitLab's client ID straight from the URL:

bbe1fe17fd3206756805

[lucadegasperi]

@taylorotwell Have you had a look at @vinkla's package? It would solve this problem without altering the database structure. In your bridge to the league's package you would only need to decrypt the string to get the client id and viceversa. The only information leaking from a numeric auto-incrementing client id (which is public) would be the number of clients the service has registered, which sometimes is not desirable.

[vinothkannans]

Let's say I got a client_secret somehow for an unknown client of example.com. So I don't know client_id. In this case, I can easily find out client_id by checking OAuth using 1 to N numbers as client_id in a for loop. But it is not possible (at least not easy) in UUID or random string.

It would be a major version break to switch to UUIDs now though.

I hope at least you can make it is happen in next major version.

[elynnaie]

I get that security through obscurity is bad, but I still don't want my clients to be able to guess other's ids, and as @lucadegasperi said, it

could expose some unwanted info about the system (like how many clients are registered in the app)

which is the main reason I care about the issue.