ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • OAuth2.0
    Spring boot 2019. 12. 24. 17:59

    OAuth2.0

    인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로 사용되는 접근 위임 개방형 표준.


    용어정리

    OAuth2.0의 전체적인 흐름에 대해 이해하려면 아래의 용어는 필수적으로 알아야한다.

    1.Resource Owner(자원 소유자)

    Resource Owner가 사람인 경우 Resource Owner는 최종 사용자를 뜻 함. 일반적으로 서비스를 이용하는 사용자라고 보면 된다 == Third-party 어플리케이션 사용자
    ex) 네이버 아이디로 a라는 사이트 로그인 할 때, 로그인 하는 사람

    2.Resource Server(리소스 서버)

    서비스(Third-party 어플리케이션)에 자신의 API를 제공하는 타사 서비스
    ex) 네이버 아이디로 a라는 사이트 로그인 할 때, 네이버

    3.Client

    고객이라 생각하지말고. OAuth2.0에서는 어떤 애플리케이션이라 생각하자. OAuth를 사용하는 주체
    == Resource Owner(자원 소유자)가 사용하려는 서비스 ex)네이버 아이디로 a라는 사이트 로그인 할 때, a사이트

    4.Authorization Server(권한 서버)

    클라이언트에게 액세스 토큰을 발급하는 서버. 자원 소유자를 인증하고
    리소스 접근 권한을 클라이언트에게 임명한다.== 인증과 인가 절차를 담당하는 제3의 서버
    ex) 네이버 아이디로 a라는 사이트 로그인 할 때, 네이버


    OAuth2.0 권한 받는 과정

    
         +--------+                               +---------------+
         |        |--(A)- Authorization Request ->|   Resource    |
         |        |                               |     Owner     |
         |        |<-(B)-- Authorization Grant ---|               |
         |        |                               +---------------+
         |        |
         |        |                               +---------------+
         |        |--(C)-- Authorization Grant -->| Authorization |
         | Client |                               |     Server    |
         |        |<-(D)----- Access Token -------|               |
         |        |                               +---------------+
         |        |
         |        |                               +---------------+
         |        |--(E)----- Access Token ------>|    Resource   |
         |        |                               |     Server    |
         |        |<-(F)--- Protected Resource ---|               |
         +--------+                               +---------------+

    (A) Client(a사이트)가 Resource Owner(사용자)에게 권한 요청.

    (B) Resource Owner(사용자)가 권한을 허가하면 Client(a사이트)는 Authorization Grant(권한 증서)를 발급 받음.
         *Authorization Grant(권한 증서)는 Client가 access token을 요청하여 얻어오는데 사용됨

    (C) Client(a사이트)가 Access token을 달라고 Authorization Server(권한 서버 ex네이버)에 요청

    (D) Authorization Grant(권한 증서)의 유효성 검증. 유효하면 access token 발급.

    (E) access token을 받은 Client(a사이트)는 Resource Server(리소스 서버 ex네이버)에 resource을 요청.

    (F) 요청 받은 Resource Server(리소스 서버 ex네이버)는 access token의 유효성을 검증하고 유효하면 요청 처리.


    Authorization Grant(권한 증서)

    Authorization Grant(권한 증서)는 Resource Owner(사용자)가 Client(a사이트)에게 권한을 허가했다는 증서이다.
    이 Authorization Grant(권한 증서)에는 총 4가지 타입이 있다.

    • -authorization code
    • -implicit
    • -resource owner password
    • -credentials, and client credentials
      이 중에 실제 구현은 resource owner password로 할 예정

    resource owner password

    Authorization Grant(권한 증서)의 4가지 타입중 한가지.
    간단히 말하면 Client에 아이디/암호를 저장한 뒤 Client가 직접 Access Token을 받는 방식이다.

    
         +----------+
         | Resource |
         |  Owner   |
         |          |
         +----------+
              v
              |    Resource Owner
             (A) Password Credentials
              |
              v
         +---------+                                  +---------------+
         |         |>--(B)---- Resource Owner ------->|               |
         |         |         Password Credentials     | Authorization |
         | Client  |                                  |     Server    |
         |         |<--(C)---- Access Token ---------<|               |
         |         |    (w/ Optional Refresh Token)   |               |
         +---------+                                  +---------------+

    (A) Resource Owner(사용자)가 Client(a사이트)에게 username, password를 준다.
    (B) Clinet(a사이트)는 Authorization Server에게 Access Token 발행을 요청
    (C) Authorization Server(네이버)는 Client(a사이트)를 인증하고, Resource Owner(사용자)의 자격이 유효하면 Access Token을 발급한다.


    출처

    https://coding-start.tistory.com/158
    https://real-dongsoo7.tistory.com/113
    http://blog.weirdx.io/post/39955
    https://tools.ietf.org/html/rfc6749

    댓글

Designed by Tistory.