OAuth2 인증

 

OAuth2란?

 

  보통은 애플리케이션에서 해당 서비스를 이용하는 사용자의 크리덴션을 관리하는 것이 일반적이다. 만약 사용자 Google 계정의 크리덴션과 연동되는 서비스를 제공한다고 가정해 보자.

이때 크리덴션을 두 개나 관리를 해야 한다. 한쪽에서 정보가 업데이트 되었을 때 다른 쪽도 업데이트를 해 줘야 한다는 번거로움도 있고, 애플리케이션이 사용자 Google 계정의 크리덴셜을 직접적으로 가지는 것은 보안상 큰 문제이다.

QAuth2는 보안된 리소스에 액세스하기 위해 클라이언트에게 권한을 제공하는 프로세스를 단순화하는 방법이다. 특정 애플리케이션에서 사용자의 인정을 직접 처리하는 것이 아니라 사용자 정보를 보유하고 있는 신뢰할 만한 써드 파티 애플리케이션에 사용자 인증을 대신 맡긴다. Resource에 대한 자격 증명용 토큰을 발급하여 클라이언트가 해당 토큰을 이용해 써드 파티 애플리케이션의 서비스를 이용하게 해 주는 방식이다.

 

---

 

동작 방식

 

인증 처리 컴포넌트

• Resource Owner: 사용하고자 하는 Resource의 소유자 (사용자)
• Client: Resource Owner를 대신해 보호된 Resource에 액세스 하는 애플리케이션 (A 애플리케이션)
• Resource Server: Client 요청을 수락하고 Resource Owner에게 해당 Resource를 제공하는 서버 (Google)
• Authorization Server: Client가 Resource Server에 접근할 수 있는 권한을 부여하는 서버 (Google)

 

Client는 Server와 상대적인 의미이다!

 

1. Resource Owner 👉 Client : OAuth2 인증 요청
2. 써드 파티 애플리케이션의 로그인 페이지로 리다이렉트
3. Resource Owner 로그인 인증 성공!
4. Authorization Server 👉 Client : Access Token 전송
5. Client 👉 Resouce Server : Owner 소유의 Resource 요청
6. Resource Server 👉 Client : Access Token 검증 후 Resource 전송

 

• Authorization Grant: Client가 Access Token을 얻기 위해 Resource Owner 권한을 표현하는 크리덴셜
• Scope: Access Token으로 접근 가능한 Resouce 범위
• Access Token: Clinet가 Resource Server에 보호된 Resource에 접근하기 위한 자격 증명 토큰
  • Authorization Code와 Client Secret을 이용해 전달받는다.

 

 

Authorization Grant 유형

 

1. Authorization Code: 권한 부여 승인 코드 방식

자체 생성한 Code를 전달하는 방식이다. Refresh Token을 사용할 수 있다.

1. Resource Owner 👉 Client: 소셜 로그인 버튼 누르기
2. Client 👉 Authorization Server: Authorization Code 요청 + Client ID, Redirect URI, 응답 타입
3. Resource Owner 로그인 진행 후 확인!
4. Authorization Server 👉 Client: Redirect URI로 Authorization Code 전달
5. Client 👉 Authorization Server: Code로 Access Token 발급 요청 + Client Secret, Redirect URI, 권한 부여 방식
6. Authorization Server 👉 Redirect URI: Access Token
7. Client 👉 Resource Server: Access Token으로 Resource 요청
8. Resource Server 👉 Client: Resource 전달

 

2. Implicit Grant: 암묵적 승인 방식

바로 Access Token을 발급한다. 자격 증명을 안전하게 저장하게 힘든 스크립트 언어를 사용하는 브라우저에게 최적화된 방식이다. Refresh Token을 사용할 수 없으며, Client Secret을 통해 클라이언트 인증 과정을 생략한다.

1. Resource Owner 👉 Client: 소셜 로그인 버튼 누르기
2. Client 👉 Authorization Server: 접근 권한 요청 + Client ID, Redirect URI, 응답 타입
3. Resource Owner 로그인 진행 후 확인!
4. Authorization Server 👉 Client: Access Token 전달
5. Client 👉 Resource Server: Access Token으로 Resource 요청
6. Resource Server 👉 Client: Resource 전달

 

3. Resource Owner Password Credential Grant: 자원 소유자 자격 증명 승인 방식

로그인 시 필요한 정보로 Access Token을 발급한다. 자신의 서비스에서 제공하는 애플리케이션의 경우에만 사용되며, Refresh Token 사용이 가능하다. Authorization Server, Resource Server, Client가 모두 같은 시스템에 속해 있을 때 사용할 수 있다.

• 네이버 👉 네이버 웹툰
• 카카오 👉 카카오 지도

1. Resource Owner 👉 Client: 소셜 로그인 버튼 누르기
2. Client 👉 Authorization Server: Access Token 요청 + Client ID, 권한 부여 방식, 로그인 정보
3. Authorization Server 👉 Client: Access Token 전달
4. Client 👉 Resource Server: Access Token으로 Resource 요청
5. Resource Server 👉 Client: Resource 전달

 

4. Client Credentials Grant: 클라이언트 자격 증명 승인 방식

Client 자신이 관리하는 Resource나 Authorization Server에 해당 Client를 위한 제한된 Resource 권한이 설정되어 있는 경우에 사용한다. 자격 증명을 안전하게 보관할 수 있는 Client에서만 사용해야 하며, Refresh Token 사용은 불가하다.