SIOS Tech. Lab | エンジニアのタメになるOSS・クラウド・認証の技術トピックス 
I’ll try to describe the problem with OAuth for Authentication.This post is based on the following article.
https://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.
 | SNS1:Service who receives permissions on UserProfile API through OAuth Authentication |
 | SNS2:Service which provide authentication to “Authentication” to A-san and “Authorization” to UserProfile API |
 | A-san:User of SNS1 |
 | 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.
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.
A-san accesses to SNS1 via Web Browser.
SNS1 redirects A-san to SNS2 Authorization Endpoint and Login Page get displayed.
OAuth consent screen get displayed on Web Browser after A-san logged in.
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.
SNS1 gets A-san’s ID via User Profile API by Access Token obtained previously.
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.
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.
 | Aku-SNS・・・the malicious SNS Service Provider managed by administrator of Aku-SNS. |
 | 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.
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.
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.
Aku-SNS redirects A-san to SNS2 Authorization Endpoint and Login Page get displayed.
OAuth consent screen gets displayed on Web Browser after A-san logged in.
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.
Aku-SNS gets A-san’s ID via User Profile API by Access Token obtained previously.
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.
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.
SNS1 redirects Administrator of Aku-SNS to SNS2 Authorization Endpoint and shows him SNS2 Login Page.
SNS2 shows administrator of Aku-SNS OAuth consent screen.
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.
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.
In this way, Administrator of Aku-SNS can act as A-san at SNS1.
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.
- SNS1 stores a target Client ID to which an Access Tokes was issued in its storage(such as database, file and so on).
- SNS2 checks whether or not a Client ID of Access Token received from SNS2 exactly matches one stored previously in SNS1’s storage.
- If exactly match, SNS2 give User Profile Information to SNS1.
The other is to use OpenID Connect.
Be the first to comment