[OAuth 2.0] Microsoft ID 플랫폼과 함께 OAuth 2.0 복기하기

대형 플랫폼이라면 갖고 있는 소셜 로그인,,, 어느 순간부터 모든 플랫폼들이 소셜 로그인 프로바이더를 제공하며, 사용자에게 간편한 Sign-In / Sign-Up 방식을 제공하고 있다.

 

사용자는 자신의 정보를 최소한으로 입력하면서 (OAuth / OpenID 를 제공하는 플랫폼으로 부터의 정보를 받으며) 다양한 웹/앱 서비스에 접근할 수 있고, 또한 사용하는 서비스들의 계정 정보를 어느정도 획일화하며 정리 할 수 있어 외우기도 간편하다.

 

이렇기에 다양한 서비스들은 유명한 프로바이더(구글, 페이스북, 네이버, 카카오 등...)를 도입하기도 한다.

 

지금까지 구글, 페이스북, 네이버, 카카오, 라쿠텐의 OAuth2.0, Steam의 OpenID 를 통해 인증 및 인가를 받아와 본 경험이 있는데, 새롭게 회사에서의 마이크로소프트 OAuth2.0을 도입한다는 소식에 개념 정리를 해보고자 한다... 얼마나 더 넣을라고 그래...

 

우선 OAuth2.0 은 무엇이고, 유사해보이는 OpenID (OIDC)는 무엇일까?

---

OAuth 2.0

OAuth("Open Authorization")는 인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는, 접근 위임을 위한 개방형 표준
이다.
이 매커니즘은 여러 기업들에 의해 사용되는데, 이를테면 아마존, 구글, 페이스북, 마이크로소프트, 트위터가 있으며 사용자들이 타사 애플리케이션이나 웹사이트의 계정에 관한 정보를 공유할 수 있게 허용한다. -위키백과

OAuth 2.0 은 인가(Authorization)을 위한 수단이다. 즉, 클라이언트에게 플랫폼에서의 허가권과 같은 Access Token을 발급한다. 보통 해당 Access Token을 바탕으로 해당 서비스의 서버는 플랫폼과 통신을 하여 사용자 정보를 받고 Sign-in & Sign-up flow를 진행시킨다.

 

반면 OpenID 는 인증(Authentication)을 위해 작동한다. OAuth 2.0위의 얇은 레이어를 갖은 구조로, 사용자 정보를 담은 ID Token을 받아 복호화하여 클라이언트의 End-User 딴에서 사용자 정보를 판단할 수 있다.

 

OpenID (OIDC)

OpenID Connect 1.0은 OAuth 2.0 프로토콜 위에 있는 간단한 ID 계층입니다. 클라이언트는 인증 서버에서 수행한 인증을 기반으로 최종 사용자의 ID를 확인할 수 있으며 상호 운용 가능하고 REST와 유사한 방식으로 최종 사용자에 대한 기본 프로필 정보를 얻을 수 있습니다.

OpenID Connect를 사용하면 웹 기반, 모바일 및 JavaScript 클라이언트를 포함한 모든 유형의 클라이언트가 인증된 세션 및 최종 사용자에 대한 정보를 요청하고 받을 수 있습니다. 사양 제품군은 확장 가능하므로 참가자들은 ID 데이터 암호화, Open 검색과 같은 선택적 기능을 사용할 수 있습니다ID 공급자 및 로그아웃(필요한 경우). -openid.net

전반적으로 OIDC를 사용하면 별도의 추가 api콜 없이 클라이언트에서 사용자의 정보를 받아올 수 있다. 

 

OpenID / OAuth - 위키백과

---

Microsoft ID 플랫폼 및 OAuth 2.0 인증 코드 흐름

OAuth를 개인/팀 프로젝트 그리고 현재 개발/유지보수 중인 서비스에 개발해보면서, 어느정도 비슷하지만 다른 플로우와 세팅에 많은 어려움을 겪은 적이 많다. Access Token을 받기까지의 flow가 각 서비스마다 다르기도 하고, 어디까지의 플로우를 서비스의 클라이언트/서버가 나누어야 할 지도 혼동을 겪기도 한다. 이 외에도 사용자의 세션 유지를 위한 Acces Token과 Refresh Token의 생명 주기에 따른 쿠키의 저장과 갱신, 그리고 활용면에서도 어려움을 겪기도 한다.

 

Microsoft의 OAuth2.0 인증 방식

우선 첫번째 팝업을 통해 사용자로부터 policy에 대한 동의를 얻고, authorization code를 받는다. 이는 access token과 refresh token을 얻기 위한 첫번째 관문이다. 해당 토큰들을 얻기 위해 authorization code와 app client id 등을 받는다.

 

이후 발급받은 access token이 Web API를 통해 활용되고, 사용자 정보를 받게되며 토큰을 받게 된다. 이후에는 refresh token을 활용하여 새로운 access token과 refresh token을 갱신하게되고, 반복할 수 있는 플로우가 완성된다.

 

추가적으로 OpenID의 스코프를 넣어, 사용자로부터 허가를 받는다면 사용이 가능하다.

---

인증코드 요청

인증코드를 요청하는 과정에 있어, 다른 프로바이더들과 달리 갖고 있는 필수 파라미터가 존재한다.

tenant 값은 해당 경로에 접근할 수 있는 사용자를 제어하기 위한 수단으로 보인다. common, organizations, consumers 및 테넌트 ID를 통해 사용자의 접근 제한을 할 수 있어 보인다.

 

code_challenge와 code_challenge_method의 이해를 위해 https://www.ibm.com/docs/ko/sva/9.0.7?topic=support-proof-key-code-exchange

PKCE 지원

를 참고하였다.

 

클라이언트의 authorization code 탈취에 의한 access token의 발급을 못하도록 조금 더 강화된 보안을 제공해준다.

 

code_verifier와 code_challenge 는 클라이언트에서 생성하여 (규칙에 맞게) 해당 파라미터로 전달하면 된다.