[Spring Framework OPEN API서비스 교육] OAuth 2.0

[OAuth 1.0의 문제점]
 - WebApp 클라이언트에서는 사용할 수 없음
 - 개발과 테스트의 어려움 : Signature
 - 인증서버와 리소스 서버의 분리가 힘듦

 

[OAuth 2.0]
 - 다양한 인증 방식 제공(4가지)
 - HTTPS 사용의 의무화
 - Signature를 사용하지 않음(Secret 평문으로 전송 -> HTTPS 사용 필수)
 - 인증&인가 단계의 간소화(앱 승인 -> 액세스 토큰 발행)

 

[OAuth 2.0과 1.0의 차이]
 - HTTPS 사용 의무
 - Access Token Secret이 없음

 

[OAuth 2.0 작동 방식]

출처 : 멀티캠퍼스

1.사용자(브라우저)가 클라이언트 웹서버에 접근한다.
2.클라이언트 웹서버는 사용자에게 앱 승인을 요청한다.(리다이렉트)
3.사용자는 인증서버에 클라이언트 승인을 요청한다.
4.인증서버는 사용자가 앱을 승인하면 redirect_uri로 이동시킨다.
5.사용자는 리다이렉트 주소를 통해 authozation code를 전달한다.
6.웹 서버는 인증 서버에 Access Token을 요청한다.
7.인증서버는 Acess Token, Refresh Token(선택적)을 응답한다.
8.웹 서버는 이제부터 사용자의 요청이 올때마다 Access Token을 이용해 Protected Resourece에 접근한다.

---

[Authorization Code grant 방식의 주요 흐름]

 Auth 단계 : 사용자가 앱을 승인하는 단계
 - 사용자는 앱을 승인하러 인증서버로 접속할 때 아래의 정보를 갖고 이동함.
 - 요청 정보 : client_id, redirect_uri, response_type=code
 - response_type=code는 사용자가 앱을 승인하면 응답을 code로 응답 받겠다는것을 의미함
 - 여기서 code는 oauth 1.0에 verifier와 동일한 의미
 - 사용자가 앱을 승인하면 code와 함께 redirect_uri로 이동시킨다.

 Access Token 획득 단계 : 클라이언트의 redirect_uri에서는 수신한 code를 이용해 Access Token을 요청한다.
 - 요청 정보 : client_id, client_secret, redirect_uri, grant_type=authorization_code
 - grant_type=authorization_code는 token을 발급 받기위해 code를 확인하겠다는 뜻
 - 요청시 주의사항 : client_id, secret은 Authorization HTTP Header를 통해서 Base64 인코딩하여 전송한다.
 - Authoziation : Basic Base64(client_id:client_secret)

 Access Token 응답 단계 : 인증서버는 요청받은 데이터가 위변조 되지 않았는지 비교하여 확인한다.