OAuth 2.0과 OpenID Connect 요약

1. 표준

• The OAuth 2.0 Authorization Framework
• OpenID Connect Core 1.0 incorporating errata set 1

2. 용어 및 약어

• 인증(Authentication) - 사용자 신원 검증
• 인가(Authorization) - 접근 권한 부여
• 정보주체(Resource Owner) - 정보 소유자
• 인증서버(Authorization Server) - 사용자 인증 수행
• 신원확인서버(Identity Provider, 줄여서 IdP) - 사용자 인증 수행 및 사용자 정보 제공 서버
• 정보제공서버(Resource Server) - 정보 서비스를 제공하는 서버

3. 질문과 답

1. OAuth 2.0과 OpenID Connect(OIDC)를 한 줄로 설명한다면?
   • OAuth 2.0 - 접근 권한 부여 프레임워크 (사용자 인증 부분을 정의하지 않고 자율에 맡김)
   • OpenID Connect - 사용자 신원 인증 규격 (OAuth 2.0에서 자율에 맡겨 두었던 사용자 인증 부분을 정의함)
     • 그렇다고 OAuth 2.0의 부분집합은 아님
     • OAuth 2.0의 확장이라고 말하는 것도 적합한 표현은 아님
     • OpenID Connect를 OAuth 2.0의 상위 계층으로 표현하는 것도 가능해 보임(HTTP를 TCP의 상위 계층으로 두는 것과 유사)
     • 규격을 정의한 단체가 다름을 떠나서 개념만 놓고 보면 OpenID Connect는 OAuth 2.0의 한 부분을 정의하고 있다.
2. OAuth 2.0의 Authorization Code Flow에서 OpenID Connect가 만드는 차이는?
   • Authorization Endpoint에 요청할 때 scope 항목의 값으로 openid를 지정
   • Token Endpoint의 응답으로 Access Token과 ID Token 전달
3. Authorization Code Flow에서 Authorization Code 전송 과정이 필요한 이유는?
   • Authorization Code 전송 과정이 없는 경우 Access Token이 브라우져를 경유하여 웹 서비스로 전달됨
     • 웹 서비스 --> 브라우져 --> IdP – (access token) --> 브라우져 – (access token) --> 웹 서비스 – (로그인 성공) --> 브라우져
       • 브라우져에서 (access token) 탈취 위험 높음
   • Authorization Code 전송 과정이 있는 경우 Access Token이 IdP에서 곧바로 웹 서비스로 전달됨
     • 웹 서비스 --> 브라우져 --> IdP – (authorization code) --> 브라우져 – (authorization code) --> 웹 서비스 – (authorization code) --> IdP – (access token) --> 웹 서비스 – (로그인 성공) --> 브라우져
       • IdP에서 웹 서비스로 곧바로 (access token)이 전달되므로 탈취 위험 낮음
   • 참고
     • 보안 관점에서 브라우져 환경보다는 서버 환경을 신뢰하고 있는 현실을 고려하는 것이 이해에 도움이 됨
     • (authorization code) 수명은 짧게 설정하고 (access token) 수명은 상대적으로 길게 설정함
4. 클라이언트는 Access Token과 ID Token을 해석할 수 있는가?
   • Access Token: 해석 불가
   • ID Token: 해석 가능
     • 대칭 알고리즘을 사용했으면 인증서버가 공유한 비밀키, 비대칭 알고리즘을 사용했으면 인증서버의 공개키를 사용하여 해석
5. UserInfo Endpoint의 용도는?
   • ID Token에 포함된 정보로는 부족해서 더 많은 사용자 정보를 요청할 때 사용
6. 브라우져가 Client Secret이나 Access Token에 접근하는 경우도 있는가?
   • 없어야 함!!!
7. IdP에 Redirect URI를 등록해 놓고도 인증요청을 보낼 때 Redirect URI 필드에 값을 채워서 보내야 하는 이유는?
   • 웹 서비스 이중화를 위해 여러 대의 서버를 구성해 놓은 경우 IdP에 여러 개의 Redirect URI를 등록해 놓을 수 있다. 그래서 각각의 웹 서비스는 자신의 Redirect URI를 인증요청 메시지에 포함해야 한다.
   • IdP에는 한 개의 Redirect URI가 등록되어 있고 인증요청 메시지는 Redirect URI를 포함하고 있지 않을 때에는 IdP 구현에 따라 등록되어 있는 값을 사용해서 정상 처리할 수도 있고 오류로 처리할 수도 있을 것 같다.

4. 사용 지침

• Implicit Flow - 쓰지 말라!!!
  • OAuth 2.0 Security Best Current Practice - IETF

    In order to avoid these issues, clients SHOULD NOT use the implicit
    grant (response type “token”) or any other response type issuing
    access tokens in the authorization response, such as “token id_token”
    and “code token id_token”, unless the issued access tokens are
    sender-constrained and access token injection in the authorization
    response is prevented.

  • Is the OAuth 2.0 Implicit Flow Dead? - Okta

    The OAuth Working Group has published some new guidance around the Implicit flow and JavaScript-based apps, specifically that the Implicit flow should no longer be used.

• Resource Owner Password Credentials Flow - 쓰지 말라!!!
  • OAuth 2.0 Security Best Current Practice - IETF

    The resource owner password credentials grant MUST NOT be used. This
    grant type insecurely exposes the credentials of the resource owner
    to the client.

  • What is the OAuth 2.0 Password Grant Type? - Okta

    The password grant type is prohibited in the latest OAuth 2.0 Security Best Current Practice. Please see oauth.net for additional information.

5. 참고 자료

• Diagrams And Movies Of All The OAuth 2.0 Flows - Takahiko Kawasaki
• Diagrams of All The OpenID Connect Flows - Takahiko Kawasaki

Written with StackEdit.