CODEWITHSUNDEEP
oauth-2.0identityserver4pkce
user3201906
user3201906

Reputation: 13

Client validation in OAuth 2.0 Authorization Grant Flow without client secret in Mobile apps

While implementing OAuth 2.0 for mobile applications using Authorization Code grant type, we can generate a clientid on Identity provider while registering the application.(we are not generating client secret for mobile application)

My question is, how Identity server verifies that the first request of response_type=code&client_id=client_id is coming from correct mobile application or not? As client id is in URL, so anyone can use read it and sends the request to authorization server.

Update: according to https://auth0.com/docs/flows/concepts/auth-code-pkce, PKCE is introduce because client secret is not secure on mobile. and malicious applications can capture the custom url.

Now, as a hacker i can get the client ID of the application by monitoring mobile default browser using development window traffic of an app say A which is register with authentication server(IS). i got he client ID of stackoverflow which i am not disclosing it here. i will create a mobile malicious mobile application which will register custom url of actual mobile app A. this app will redirect with same clientid and redirect url and with PKCE challenge. Now, how IS will be able to identify whether request id coming from correct client or not. Since, as mentioned in link, if i am able to register malicious application to capture custom redirect url request of mobile, then i will be able to capture authentication code and perform rest of the workflow using malicious application.

Google takes the bundle identifier(IOS) or application signing(Android) while creating application. does it help somehow identifying application??

Upvotes: 0

Views: 799

Answers (1)

andrija
andrija

Reputation: 1202

Oauth2 requires SSL, so not everyone can read your url parameters. Url is also encrypted in SSL request. Your client asks DNS server for ip address. It sends request url without parameters to DNS. After obtaining ip address encrypted request is sent to that ip address.

Public clients are less safe than private clients, there is no doubt about that.

Answer on Edit part: PKCE gives additional protection. First you have to generate some random value and calculate hash of that random value. In first request you send calculated hash and get code. In second request you send code and random value. This way if advesary steals your code he cannot get token because he needs your random value. Only you can know random value used to create hash, because if advesary knows your hash he cannot calculate random value from hash. When you send token request to IS, IS calculates hash of your random value and compares it to the hash you sent in the code request. If they do match it is proof that you are the same guy who asked for code.

Upvotes: 1

Related Questions