Spring Security(OAuth2)

OAuth

써드 파티 앱에서 인증을 대신하여 Resource에 대한 토큰을 발급하면,
Client(서버)가 해당 토큰을 이용해 써드 파티 앱의 서비스를 사용하게 해주는 방식

1. 써드 파티 앱 API의 직접적인 사용
2. 추가 인증 서비스

Resource Owner
서비스를 이용하는 사용자

Client
Resource에 액세스하는 애플리케이션(서버)

Authorization Server
Client에게 Resource 접근 권한을 부여하는 서버

Resource Server
발급 토큰으로 Client의 요청을 수락하고 Resource Owner에게 해당하는 Resource를 제공
Refresh Token 사용 가능

Authorization Grant
Resource Owner의 크리덴셜(Credential)

Scope
액세스 토큰을 사용하여 액세스할 수 있는 Resource의 범위

Authorization Grant 유형

Authorization Code Grant

권한 부여 승인 코드 방식

1. Resource Owner가 Client에게 요청
2. Client가 Authorization Server에 Authorization Code를 요청
   (Client ID, Redirect URI, 응답 타입을 함께 전송)
3. Resource Owner가 Authorization Server에 로그인
4. Authorization Server가 Client에게 Redirect URI로 인증코드를 전달
5. Client가 Authorization Server에 Access Token 발급 요청:
   (Client Secret, Redirect URI, 권한 부여 방식, 인증코드와 함께 전송)
6. Authorization Server가 Redirect URI로 Access Token을 발급

Implicit Grant

암묵적 승인 방식
Refresh Token 사용 불가
자격증명을 보관이 힘든 Client(스크립트 언어)에게 최적화된 방식

1. Resource Owner가 Client에게 요청
2. Client가 Authorization Server에 Access Token요청
   (Client ID, Redirect URI, 응답 타입을 함께 전송)
3. Resource Owner가 Authorization Server에 로그인
4. Authorization Server가 Redirect URI로 Access Token을 발급

Resource Owner Password Credential Grant

자원 소유자 자격 증명 승인 방식
Authorization Server, Resource Server, Client가 모두 같은 시스템에 속해 있을 때만 사용이 가능
Refresh Token 사용 가능

1. Resource Owner가 Client에게 요청
   로그인에 필요한 정보(Username, Password)가 함께 전달됨
2. Client가 Authorization Server에 Access Token요청
   (Client ID, 권한 부여 방식, 로그인 정보를 함께 전송)
3. Authorization Server가 Client에게 Access Token을 전달

Client Credentials Gran

클라이언트 자격 증명 승인 방식
Client 본인이 관리하는 Resource나 Authorization Server에 해당 Client를 위한 제한된 Resource 접근 권한이 설정되어 있는 경우 사용할 수 있는 방식
자격 증명 보관관리가 필요
Refresh Token 사용 불가

1. Client가 Authorization Server에게 Access Token요청
2. Authorization Server가 Client에게 Access Token을 전달