즉,
이미 사용자 정보를 가지고 있는 *웹 서비스*(Github, Google, Facebook, KaKao, naver 등)에서
1)사용자 인증을 대신해주고
2)접근 권한에 대한 토큰을 발급한 후
3)이를 이용해 서버에서 인증이 가능하다.
검증되지 않은 App에서 OAuth를 사용해 로그인하면
→ 유저의 민감한 정보가 직접적으로 App에 노출되지 않고,
→ 인증권한에 대한 허가를 미리 유저에게 구해야 하기 때문에 더 안전하게 사용할 수 있다.
Resource Owner
: 사용자이며 정보 제공자이기도 하기 때문에 Resource Owner라고 한다.Client
: Resource Owner를 대신하여 보호된 리소스에 액세스하는 애플리케이션을 말한다.Local Server
: Client의 요청을 수락하고 응답할 수 있는 서버.Resource Server
: 사용자의 정보를 저장하고 있는 서버.Authorization Server
: 인증을 담당하고 있는 서버로, Access Token을 발급하는 인증 서버를 말한다.Authorization Grant
: Client가 Access Token을 얻는 방법을 의미한다. 다음과 같은 방법들이 주로 사용된다.Authorization Code
: Authorization Grant의 한 타입으로 Access Token을 발급받기 위한 Code를 의미한다.Access Token
: 보호된 리소스에 액세스하는 데 사용되는 인증 토큰으로, 이 Access Token으로 Resource Server에 접근할 수 있다.Refresh Token
: 발급받은 Access Token이 만료될 시 Refresh Token을 통해 새로운 Access Token을 받급받을 수 있다.Authorization Code
를 받아 이를 통해 → Access Token을 받는 방식
이다.
Authorization Code Grant Type은 Access Token
이 사용자나 브라우저에 표시되지 않아
→ Access Token
이 다른 사람에게 누출될 위헝이 줄아든다.
Authorization Code Grant Type 인증 흐름
1. 사용자 → 클라이언트 : 사이트 접속
2. 클라이언트 → Auth Sever : 로그인
3. Auth Sever → 클라이언트 :Authorization Code
전달
4. 클라이언트 → Local Sever :Authorization Code
전달
5. Local Sever → Auth Sever :Access Token
요청
6. Auth Sever → Local Sever :Access Token
전달
7. Local Sever → Resource Sever : 유저정보 요청
8. Resource Sever → Local Sever : 유저 정보 전달
9. Local Sever → 클라이언트 : 유저 정보 전달
Access Token
이 만료되었을 때Refresh Token
을 활용해 새로운 Access Token으로 교환
하는 데 사용된다.Refresh Token
을 통해 사용자와의 추가 상호 작용 없이 계속 유효한 액세스 토큰을 가질 수 있다.**Refresh Token Grant Type 인증 흐름
1. Local Sever → Auth Sever :Refresh Token
을 통해 새로운Access Token
요청
2. Auth Sever → Local Sever : 새로운Access Token
전달