[Spring] OAuth 2.0 원리 이해

생활코딩 님의 유튜브 [WEB2-OAuth] 강의들을 보고 정리했습니다. 

---

1. 수업 소개

• accessToken은 id, pw가 아니다
• 그들의 서비스 중 내 서비스가 필수적인 것만 부분적으로 허용
• accessToken 획득해서 그들의 서비스에 접근

 

2. 역할

• Resource Server 데이터 가지고 있는 서버 , Authorization Server 인증 처리 전담 (공식매뉴얼에서는 분리)
• Resource Owner 사용자
• Client 내가 만드는 서비스

 

3. 등록

• Client가 Resource Server를 이용하기 위해서는 승인을 사전에 받아야 함(register)
• Client ID(서비스 식별자), client secret(외부 노출되면 X; 엄청난 보안사고), authorized redirect URIs(Resource server가 authorized code를 전달하기 위한 주소)

 

4. Resource Owner의 승인

• client는 Redirect URIs에 해당하는 페이지를 구현해 놓고 준비하고 있어야 함
• Resource Owner(user)가 client에 접근할 때 소셜 로그인 화면 표시
• 아래의 주소로 Resource owner는 Resource server에 접근하는데 해당 서비스에 로그인이 안 되어 있다면 먼저 인증 거침 
• 그 후 client id 정보가 Resource server에게 있는지 확인, 접속을 시도하는 요청의 redirect url 값이 같은지를 확인하고 다르면 작업을 끝냄
• 같다면 scope에 해당하는 권한을 client에게 부여할 것인지 확인하는 메시지 전송
• 동의하면 scope에 대한 정보를 추가적으로 갖게 됨

https://www.youtube.com/watch?v=UH5XnjkBqKE&list=PLuHgQVnccGMA4guyznDlykFJh28_R08Q-&index=4

https://www.youtube.com/watch?v=UH5XnjkBqKE&list=PLuHgQVnccGMA4guyznDlykFJh28_R08Q-&index=4

https://www.youtube.com/watch?v=UH5XnjkBqKE&list=PLuHgQVnccGMA4guyznDlykFJh28_R08Q-&index=4

5. Resource Server의 승인

• Resource Owner가 허락한 후에 Resource Server는 바로 accessToken을 발급하는 게 아니라 authorization code를 붙여 리다이렉션하게 함
• Resource Owner는 client로 전달, client는 이 authorization code를 알게 됨
• Client는 Resource Server에게 authorization code, client_secret 비밀 정보를 전달
• Resource Server는 요청 url에 붙은 정보가 자신이 가지고 있는 정보와 일치하는지 확인

https://www.youtube.com/watch?v=O0Rx9SRPzs4&list=PLuHgQVnccGMA4guyznDlykFJh28_R08Q-&index=5

https://www.youtube.com/watch?v=O0Rx9SRPzs4&list=PLuHgQVnccGMA4guyznDlykFJh28_R08Q-&index=5

https://www.youtube.com/watch?v=O0Rx9SRPzs4&list=PLuHgQVnccGMA4guyznDlykFJh28_R08Q-&index=5

6. 액세스 토큰 발급

• OAuth의 핵심: 액세스 토큰 발급
• Authorization code(임시 비밀번호) 지우고 accessToken 발급 해서 client에게 전달 
• User id = 1 사용자에게 유효한 기능 b, c에 대해 열려있음

https://www.youtube.com/watch?v=BofCK1oWAyc&list=PLuHgQVnccGMA4guyznDlykFJh28_R08Q-&index=6

7. API 호출

• 액세스 토큰 전달 방법
  - Uri 뒤에 쿼리 파라미터 붙여서 호출 or Authorization: Bearer <access_token> 정보를 헤더에 붙여 전송
  - 전자는 ?access_token=<access_token>
  - 후자는 curl -H "Authorization: Bearer <access_token>" api주소 로 테스트 가능
  - curl(client url): url로 데이터를 전송하여 서버에 데이터를 보내거나 가져올 때 사용하기 위한 명령줄 도구 및 라이브러리 
  [https://inpa.tistory.com/entry/LINUX-📚-CURL-명령어-사용법-다양한-예제로-정리]
• 뒤 방법이 더 안전, 표준
• 전자는 될 수도 안 될 수도, 매뉴얼 보고 진행

8. refresh token

• Access Token 발급할 때 refresh token도 같이 발급하는 경우 많음
• Access token의 수명이 다했을 때 authorization server에 refresh token을 넘겨 다시 발급, refresh token을 다시 발급해 주기도 하고 아니기도 하고 그럼

https://www.youtube.com/watch?v=9eKIYjcPXp4&list=PLuHgQVnccGMA4guyznDlykFJh28_R08Q-&index=8

https://datatracker.ietf.org/doc/html/rfc6749#section-1.5

RFC 6749: The OAuth 2.0 Authorization Framework

9. 수업을 마치며

• Client 입장에서 Resource server를 통해 resource owner의 신원을 인증할 수 있음
• Access token(like id/pw): Resource server 상에서 resource owner의 고유한 식별자 획득
• Federated identity(연합-): 다른 서비스와의 연합을 통해 사용자를 식별하는 인증체계
• Oauth를 이용하는 궁극의 목적: API 제어 -- Restful, JSON, XML