새로운 서비스를 이용하기 위해서 회원가입할때 흔히 네이버 계정으로 가입하기
, 카카오 계정으로 가입하기
, 구글 계정으로 가입하기
를 통해 가입한 경험이 있을 것입니다.
현재 이용하고 있는 velog만 해도
귀찮은 절차 없이 소셜 계정으로 간편하게 회원 가입을 할 수 있는데요,
여기서 다른 서비스의 고객 정보를 안전하게 건네받기 위해 사용하는 방법이 OAuth2.0입니다!
우리가 Github 계정으로 Velog에 가입하는 과정을 간단하게 이렇게 나타낼 수 있습니다.
여기서 유저는 클라이언트 서비스에 가입하려는 고객, 클라이언트 서비스는 고객의 정보를 안전하게 Github으로부터 가져오려는 Velog, Authorization Server는 고객의 정보를 갖고있는 Github이 됩니다.
위의 1와 4과정 즉, Access Token을 요청하고 응답받는 과정을 표준화한 것이 바로 OAuth2.0이라고 할 수 있습니다.
이때 고객에게 과정 2에서 보여지는 화면은 다음과 같습니다.
OAuth2.0에는 크게 세가지 Flow가 있습니다.
OAuth2.0의 가장 대표적인 흐름은 다음과 같습니다.
주황색의 App XYZ가 사용자가 가입하려고 하는 Velog, 초록색의 Server ABC가 사용자의 정보를 가지고 있는 Github로 생각하면 이해가 빠릅니다.
그림이 복잡해보이지만 1번부터 차례대로 따라가면 간단!
절차는 크게
의 과정으로 볼 수 있습니다.
A~D의 과정은 발급받은 Access Token으로 실제 사용자의 데이터에 접근하는 과정을 나타냅니다.
Access Token 이전에 Auth Code를 발급받는 절차를 거치는 이유는 Auth endpoint와 token endpoint의 역할을 구분하기 위해서 입니다.
OAuth2.0에서 Client는 크게 credential와 public으로 나뉩니다.
비밀값을 안전하게 저장할 능력이 되는 Credential의 경우, OAuth의 흐름은 다음과 같습니다.
이때 Server가 Client App을 알고 있고 인증이 가능하고, Client를 일종의 자신의 User라고 판단한다고 가정합니다.
Auth Code를 발급받는 추가 과정없이 바로 Access Token에 대한 요청&응답이 이루어집니다.
Access Token을 발급받고 난 뒤의 과정은 앞의 흐름과 동일합니다.
왜 User에 대한 Authentication 과정이 빠졌지?하고 의문이 들 수 있는데, 이 과정은 Client App이 서버에 특정 유저에 대한 정보를 요청하는 것이 아닌, 일반적인 Resource를 요청하는 경우이기 때문입니다.
Refresh Token은 유효기간이 정해진 Token으로 Access Token을 발급받을때 같이 발급됩니다. 한번의 인증을 거친 후, refresh token을 제시하면 바로 인증이 가능합니다.
-> 재인증시 활용하는 Token이라고 할 수 있습니다.
Refresh Token의 경우, 다음과 같이 추가 과정 없이 바로 Access Token의 재발급이 이루어집니다.
앞서 본 세가지 흐름중 Authorization Code flow는 가장 일반적인 경우, Client Credentials Flow와 Refresh Token Flow는 필요할때 그때그때 요청하는 흐름입니다.
https://www.authlete.com/
[OAuth 2.0] OAuth란?
네트워크 보안 강의를 들으면서 정리한 내용입니다. 강의를 들으면서 더 궁금했던 부분은 구글링을 통해 공부한 내용인데 혹시라도 틀린 부분이 있다면 알려주세요!!!