OAuth2 정리

OAuth2

Open + Authorization Version 2를 의미함.

• Authorization Framework : 해당 사용자가 특정 행동을 할 수 있는 권한을 부여하는 것.
  • ex) 페이스북 계정을 통한 소셜로그인 -> 로그인한 애플리케이션에서 페이스북에 등록된 정보를 사용할 수 있음.
• Delegated Framework : 아이디 / 패스워드 없이도 로그인이 가능하고, 사용자에게 제한된 권한만을 부여하는 식으로 작업할 수 있음.

OAuth 2.0 등장 이전의 로그인방식은 아래와 같았음

• 어느 SNS로 로그인할지 체크
• 아이디 / 패스워드 입력
• 로그인할 애플리케이션이 이 정보를 직접 SNS에 들고가서 로그인하는 방식.

보안에 취약하다.

• 서드파티 애플리케이션에 직접 정보를 줘야 하고
• 서드파티는 해당 사용자의 모든 정보에 언제든 접근할 수 있음
• 서드파티 애플리케이션이 얼마나 사용자 정보를 안전하게 보관하고 있는지 확신할 수 없음

OAuth2의 작동방식

1. 사용자는 해당 SNS 서비스에 직접 로그인.
2. 로그인하면, SNS 서비스에서 '이러이러한 권한을 서드파티 앱에서 요구하는데 허용할 것인지' 확인
3. 확인하면, 해당 리소스에만 접근할 수 있는 토큰이 서드파티에 전달됨
4. 서드파티 앱은 해당 토큰으로 필요한 정보를 가져옴.

OAuth 2.0 Roles

• Resource Owner : 접근할 대상인 Resource의 소유권한이 있는 주체. User라고도 부른다.
• Client : 사용자 정보에 접근을 요청하는 대상.
• Resource Server : 실제 리소스를 저장하고 있는 곳. 소셜로그인일 경우 SNS 서버 (구글, 페이스북 등) 을 말하며, MicroService 형태일 경우 각각의 서버들이 전부 Resource server가 된다.
• Authorization Server : Client Application에 access token을 발행하는 주체. Authenticating the resource owner / obtaining authorization. 소셜로그인을 제공하는 서버 대부분이 Authorization Server도 보유하고 있다.

Spring Security 프로젝트의 상황

원래 OAuth 프로젝트에서 Client / Resource / Authorization 기능을 한 프로젝트에 전부 지원하는 방식이었으나, Spring Security 5부터 새로운 형태의 프로젝트로 진행하고 있음. 기존 프로젝트는 2021년 5월까지 Maintenance 형태로 유지한다고 함.

Authorization 서버의 새 버전은 현재 개발 중이라고 함.

Client Server

Resource Owner (User)가 Resource Server에 필요한 데이터를 요청할 때 사용하는 대상.

• 모바일 어플리케이션이나 웹, 리눅스 터미널 앱 또는 브라우저 기반 SPA 등 여러 종류
• Authorization Server와 http로 통신하며, Register 이후 client ID / client Secret key를 발급받는다.

Client에도 크게 두 개의 타입이 있음

• Confidential Client: Auth Server가 발급한 Secret Key를 안전하게 보관할 수 있는 클라이언트.
• Public Client: Secret Key를 안전하게 보관한다고 보장할 수 없는 경우. 사용자 디바이스에 설치된 앱 (PC / Mobile)이나 브라우저 위에서만 동작하는 SPA 등이 해당된다.
  • 코드가 디컴파일되거나 외부에 노출될 경우 cannot guarantee the confidentiality.

클라이언트 타입이 다르기 때문에, OAuth Server는 서로 다른 Auth Flow를 제공한다.

Access Token

Client는 Access Token을 발급받으면, Resource Owner에게 직접 정보를 요청받지 않고도 원하는 리소스에 접근 요청을 할 수 있다. 따라서 이 값은 안전하게 관리되어야 한다.

• Secure location에 보관되어야 하며
• Https를 사용해서 통신해야 한다.
• 즉, Access Token이 오고가는 주체는 Client, Resource Server, Authorization Server여야만 한다.

Access Token의 Type

• Idnetifier Type -> 고정된 길이의 문자열 형태로 생성하는 것. Authorization Server가 세부 설정을 선택한다. 데이터베이스에 저장된 어떤 값에 접근할 수 있는 identifier라는 의미

Header, Payload, Signature 형태로 구성된 형태.

• Self-contain the authorization information -> jwt 같은 형태. 토큰 자체적으로 정보를 담고 있는 형태를 말한다. jwt의 경우 Base64 형태로 인코딩되어 있음.
  • base64처럼 공개된 방식의 인코딩을 사용할 경우, 민감한 정보를 저장해서는 안 된다.

OpenID Connect (OIDC)

토큰 자체는 Authenticated User 정보와는 직접 관련이 없는 랜덤 문자열이다. Client에게 Authenticated User에 관련된 추가정보를 제공하기 위한 Identity Layer가 OIDC. 이 Identity Layer를 'Identity Provider'라고도 한다.

Access Token 외에도 ID Token이라는, Currently Authenticated User 기본정보를 Client에 제공하는 식.

• ID Token : validate the user who they claim to be
• Access Token : Requested Resource에 접근 가능한지 검증하는 토큰

아래와 같이 다양한 형태의 추가정보를 담을 수 있다.