[OAuth2.0] 이론

동작방식

Resource Owner(RO) : 사용자

Client(CL) : 서비스 애플리케이션(프론트 + 백)

Resource Server(RS) : 써드파티 애플리케이션 서비스 서버

Authorization Server(AS) : 써드 파티 애플리케이션 인증 서버 

 

1. RO는 CL역할을 하는 웹앱에게 OAuth2 인증 요청

2. CL은 RO의 계정정보를 관리하고 있는 AS(써드파티 애플리케이션)의 로그인페이지로 리다이렉트 시킴

3. RO는 AS에 로그인 하고, 인증이 성공하면, AS는 CL에게 AccessToken을 전달

4. 이제 RO가 CL에게 요청을 위임하게됨. RO가 RS에 본인의 정보를 요청할 때, CL가 RS에게 대신 요청하는 방식

5. 따라서, RO는 CL으로부터 CL에서 생성된 Authorization을 받아 사용하게 될 것임

---

OAuth2 인증 프로토콜 용어

Authrization Grant : Client가 토큰을 얻기 위한 수단

  1. Authorization Code (인증 코드)

1. 기본 범용 방식

2. 리프레쉬 토큰 사용 가능

  2. Inplicit Grant Type (암묵적 승인)

1. 자격 증명을 안전하게 저장하기 힘든 Client(JS 등 스크립트 언어를 사용하는 브라우저)에게 최적화된 방식

2. 리프레쉬 토큰 사용 불가

3. 서드파티 인증 서버는 Client Secret을 통해 Client 인증 과정을 생략함

4. 권한 부여 승인 요청시, 응답타입을 토큰으로 지정하여 요청

  3. Client Credentials (자원 소유자 자격 증명 승인) : 

1. Authorization Server, Resource Server, Client가 같은 시스템에 속해 있을 때만 사용 가능

    (자체 인증 서버 및 자사의 다른 서버 서비스)

    (예를 들어, 네이버 인증 후 네이버 웹툰, 쇼핑 등 사용)

2. 리프레쉬 토큰 사용 가능

  4. Resource Owner Password Credential (클라이언트 자격 증명 승인)

1. 자체 서비스 안의 자체 로그인 (자체 인증 및 자사 서비스)

2. 리프레쉬 토큰 사용 불가

AccessToken : Client(자체 서비스)에서 Resource서버에 접근하기 위해 발급받은 코드

Scope : 액세스토큰으로 접근 가능한 Resource 범위

---