The problem with OAuth for Authentication

I’ll try to describe the problem with OAuth for Authentication.This post is based on the following article.

http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html

According to this article, It seems that OAuth for Authentication with Implicit Flow allows a malicious user to access a specific site on behalf of any other user.

I’ll try explain about this clearly in this post.

What is OAuth Authentication?

OAuth Protocol is suitable not for Authentication, but for Authorization which grants permissions to use APIs provided by SNS2 to a user.In this case, OpenID Connect is suitable.But inappropriate ways allows you to authenticate a user by OAuth.In this chapter, I’ll describe this way with some figures.

At first, I’ll show you characters in this chapter.

Screen Shot 2019-02-25 at 10.27.50 SNS1:Service who receives permissions on UserProfile API through OAuth Authentication
Screen Shot 2019-02-25 at 10.27.56 SNS2:Service which provide authentication to “Authentication” to A-san and “Authorization” to UserProfile API
Screen Shot 2019-02-25 at 10.27.41 A-san:User of SNS1
Screen Shot 2019-02-25 at 10.28.02 Administrator of SNS1

 

I assume that SNS2 uses Implicit Flow.At first, Administrator of SNS1 must fill out the application form provided by SNS2 for SNS1 to be registered as OAuth Application of SNS2, and must make an application to use some permissions, such as “Read Profile”,”Update User” and so on, provided by SNS2.OAuth Authentication needs a permission to read user’s profile information.

Screen Shot 2019-02-25 at 22.43.24

 

After registration, Client ID and Client Secret are issued to Administrator of SNS1 and stored in storage such as relational database.This is the initial process to use OAuth.

Screen Shot 2019-02-25 at 22.53.29

 

A-san accesses to SNS1 via Web Browser.

Screen Shot 2019-02-25 at 22.57.10

 

SNS1 redirects A-san to SNS2 Authorization Endpoint and Login Page get displayed.

Screen Shot 2019-02-25 at 23.20.10

 

OAuth consent screen get displayed on Web Browser after A-san logged in.

Screen Shot 2019-02-25 at 23.37.59

 

Due to Implicit Flow, SNS2 redirect A-san to Callback URL pre-configured in the registration of SNS2 as OAuth Client Application with Access Token return via the hash/fragment of the URL.SNS1 extracts Access Token from the hash/fragment and stores it in SNS1 storage such as a relational database.

Screen Shot 2019-02-26 at 11.20.01

 

SNS1 gets A-san’s ID via User Profile API by Access Token obtained previously.

Screen Shot 2019-02-26 at 11.21.57

 

SNS1 finds a user accessing from SNS1 to be “A-san” by UserProfile Infofmation obtained by Access Token from SNS2 and gives A-san’s information to A-san.It seems to be no problem in the case of all of the sites including SNS1 being not malicious.

Screen Shot 2019-02-26 at 11.22.34

The problem with OAuth for Authentication

In this chapter, I’ll show you security risks when using OAuth Authentication.This chapter has the following new characters.

Screen Shot 2019-02-25 at 12.16.16 Aku-SNS・・・the malicious SNS Service Provider managed by administrator of Aku-SNS.
Screen Shot 2019-02-25 at 12.14.47 Administrator of Aku-SNS・・・Administrator of Aku-SNS who is trying to obtain A-san’s Access Token and act as A-san at SNS1.

I’ll try to describe how administrator of Aku-SNS obtain A-san’s Access Token.At first, as administrator of SNS1 did at the previous chapter, Administrator of Aku-SNS must fill out the application form provided by SNS2 for Aku-SNS to be registered as OAuth Application of SNS2, and must make an application to use some permissions, such as “Read Profile”,”Update User” and so on, provided by SNS2.OAuth Authentication needs a permission to read user’s profile information.

Screen Shot 2019-02-26 at 9.12.58

 

After registration, Client ID and Client Secret are issued to Administrator of Aku-SNS and stored in storage such as relational database.This is the initial process to use OAuth.This process is same as SNS1 did in the previous chapter,too.

Screen Shot 2019-02-26 at 9.13.52

 

A-san accesses to Aku-SNS.But he dosen’t know that Aku-SNS is malicious and is trying to act as A-san at SNS1 by using A-san’s Access Token.

Screen Shot 2019-02-26 at 9.16.46

 

Aku-SNS redirects A-san to SNS2 Authorization Endpoint and Login Page get displayed.

Screen Shot 2019-02-26 at 9.26.11

 

OAuth consent screen gets displayed on Web Browser after A-san logged in.

Screen Shot 2019-02-26 at 9.29.32

 

Due to Implicit Flow, SNS2 redirect A-san to Callback URL pre-configured at the registration of SNS2 as OAuth Client Application with Access Token returned via the hash/fragment of the URL.SNS1 extracts Access Token from the hash/fragment and stores it in Aku-SNS storage such as a relational database.

Screen Shot 2019-02-26 at 9.35.50

 

Aku-SNS gets A-san’s ID via User Profile API by Access Token obtained previously.

Screen Shot 2019-02-26 at 9.34.11

 

Aku-SNS finds a user accessing from Aku-SNS to be “A-san” by UserProfile Infofmation obtained by Access Token from SNS2 and gives A-san’s information to A-san.

Screen Shot 2019-02-26 at 9.43.52

 

In this way, Aku-SNS obtained A-san’s Access Token.I’ll show you how administrator of Aku-SNS act as A-san at SNS1 with Access Token obtained previously.

Administrator of Aku-SNS accesses to SNS1.

Screen Shot 2019-02-26 at 9.52.17

 

SNS1 redirects Administrator of Aku-SNS to SNS2 Authorization Endpoint and shows him SNS2 Login Page.

Screen Shot 2019-02-26 at 9.56.06

 

SNS2 shows administrator of Aku-SNS OAuth consent screen.

Screen Shot 2019-02-26 at 10.05.16

 

Due to Implicit Flow, SNS2 redirect administrator of Aku-SNS to Callback URL pre-configured at the registration of SNS2 as OAuth Client Application with Access Token returned via the hash/fragment of the URL.It is very important that administrator of Aku-SNS modified URL including Location Header which was returned to him as HTTP response and replaced Access Token including the hash/fragment of the URL to A-san’s Access Token obtained previously as the following figure described.

Screen Shot 2019-02-26 at 10.16.34

 

SNS1 receives Access Token which is redirected from Aku-SNS Administrator’s Web Browser and request A-san’s Profile Information to SNS2 with Access Token obtained previously.SNS2 receives the Access Token and compare it with A-san’s Access Token stored in the storage(such as Relational Database).If exactly match, SNS2 returns Profile Information including A-san’s User ID to SNS1.

Screen Shot 2019-02-26 at 11.23.41

 

In this way, Administrator of Aku-SNS can act as A-san at SNS1.

Screen Shot 2019-02-26 at 10.42.34

Solutions

I’ll suggest two solutions.

One is that SNS2 verifies where the Access Token issued from after receiving it from SNS1.The details are shown as below.

  1. SNS1 stores a target Client ID to which an Access Tokes was issued in its storage(such as database, file and so on).
  2. SNS2 checks whether or not a Client ID of Access Token received from SNS2 exactly matches one stored previously in SNS1’s storage.
  3. If exactly match, SNS2 give User Profile Information to SNS1.

The other is to use OpenID Connect.

 

 

ご覧いただきありがとうございます! この投稿はお役に立ちましたか?

役に立った 役に立たなかった

0人がこの投稿は役に立ったと言っています。

コメント投稿

メールアドレスは表示されません。


*