쉽게 풀어 쓴 OAuth (Federated Identity)

OAuth에 대해 알아보기 전에..

다시 한번 복습..

 

Client가 특정 서비스를 사용하기 위해서는 필요한게 있다.

 

바로..

인증 (Authentication)

인가 (Authorization)

두가지 이다. (매번 봐도 헷갈리는 녀석들..)

 

인증(Authentication)..

유저가 누구인지 확인하는 절차이다.

로그인에 해당한다.

(로그인)

 

인가(권한, Authorization)..

유저가 요청하는 자원에 대해 권한이 있는지 확인하는 절차이다.

이 유저가 xxx을 할 권한이 있는지 검증 하는 절차에 해당한다.

(로그인을 했어도 Admin 권한이 없으면 못하는게 있지)

(권한 레벨)

 

 

들어가기에 앞서..

OAuth가 왜 생기게 되었는지 간단하게 서술 하겠다..

 

최초에 사용자, 넥슨, 구글이 존재하였다. (예시)

 

<가정>

1. 사용자는 넥슨 게임을 하고 있다.

2. 넥슨은 사용자를 대신해서 사용자의 구글 캘린더에 연동해서

게임을 한 날짜를 기록하는 서비스를 하고 싶었다. (사용자도 원하고 동의함)

 

그러기 위해서는

넥슨은 사용자로 부터 사용자의 구글 계정에 접근 할 수 있도록 허가를 받아야 한다.

 

가장 쉬운 방법으로는

넥슨은 사용자로 부터 사용자의 구글 계정 아이디/비밀번호를 받아서 저장 하고 있다가..

넥슨이 사용자를 대신해 구글 서비스를 사용할 때, 저장 하고 있던

사용자의 구글 계정 아이디/비밀번호를 이용하는 방법이다.

 

이 방법은 정말 간단하고 강력한 방법이다.

왜냐하면, 넥슨은 사용자의 아이디/비밀번호만 받아서 쓰면 되고

사용자의 아이디/비밀번호를 이용하면

사용자가 사용할 수 있는 구글 서비스 전체를 다 쓸 수 있기 때문이다.

 

이 방법은 굉장히 위험한 방법이고 3명 모두 원하지 않는다.

1. 사용자 입장

넥슨에게 나의(사용자) 구글 아이디/비밀번호를 맡겨야하는 상황이다.

(못 믿겠다!!)

2. 넥슨 입장

사용자들의 구글 아이디/비밀번호를 저장하고 있다가 유실되면..

(나도(넥슨) 위험 부담이 너무 크다!!)

3. 구글 입장

우리(구글) 서비스를 사용하는 사용자의 아이디/비밀번호를 넥슨이 뭔데 가지고 있는거야

(못 믿겠다!!)

 

이러한 상황에서 사용할 수 있는게 OAuth이다

 

그러면 사용자의 아이디/비밀번호를 대체하는 건 무엇인가..

바로 Access Token이다.

사용자의 요청에 의해서 구글은 넥슨에게 Access Token을 발급해준다.

 

구글은 넥슨에게 Access Token을 발급할 때

사용자에게 넥슨에게 어떤 서비스까지 오픈 할 것인지 동의를 구한다.

(서비스는 사용자의 정보가 될 수도 있다)

 

그러면 넥슨은 Access Token을 이용해서

사용자가 동의한 범위 내에서 사용자의 구글 서비스를 사용할 수 있게 된다.

 

좀 더 생각해보면...

넥슨이 이용할 사용자의 구글의 서비스가 회원 정보라면..

넥슨은 해당 정보를 이용해 사용자를 식별할 수 있다.

 

그래서..

넥슨은 사용자를 넥슨 회원으로써 회원 가입시킬 수 있는 것이고,

넥슨은 사용자 대신에 사용자의 구글 서비스를 이용할 수 있는 것이고,

넥슨은 식별이 된 사용자에게 넥슨의 서비스를 이용 할 수 있도록 권한을 부여할 수 있다.

 

 

이제 본격적으로 OAuth에서 사용하는 용어로 매핑 해보자.

 

구글은 Resource Server이다.

넥슨이 사용자 대신에 사용하고자 하는 서비스(리소스)를 가진 서버라는 의미에서 나왔다.

 

사용자는 Resource Owner이다.

구글의 서비스(리소스)를 가진 자라는 의미에서 나왔다.

 

넥슨은 Client이다.

사용자의 구글의 서비스(리소스)를 가져가는 자라는 의미에서 나왔다.

 

<여기서 참고>

Authorization Server 라는 녀석이 존재한다.

Authorization Server는 구글이며, 인증과 관련된 처리를 전담하는 서버라고 보면된다.

(Resource Server는 구글의 서비스(리소스)를 가진 서버)

 

 

 

이제..

OAuth의 전체적 절차에 대해 알아보자

 

Client(넥슨)은 아무리 Resource Owner(사용자)가 허가를 해줬다 해도..

Resource Server(구글)에 있는 Resource를 Resource Owner(사용자) 대신 쓰고싶은 Client(넥슨)가

Authorization Server(구글)에게 사전에 승인(등록) 받아 놓지 않으면

Client는 Resource Server의 서비스를 사용할 수 없다.

 

그래서..

처음엔 Client가 Authorization Server에 등록을 해줘야한다.

 

1. 등록 과정

 

<Client가 알게되는 정보>

Authorization Server는 Client에게 보통 2가지 정보를 준다.

1. Client ID

Resource Server가 Client를 식별하는 식별자 아이디

 

2. Client Secret

Client 아이디에 대한 비밀번호

 

<Authorization Server가 알게되는 정보>

Client는 Authorization Server에 1가지 정보를 줘야한다.

 

1. Authorized redirect URIs

Authorization Server가 Client에게 권한을 부여하는 과정에서

Client한테 Authorized Code를 전달 해줄 것이다.

 

그러니까 Authorized redirect URIs 는..

Client가 Authorization Server로 부터 Authorization Code를 받을 주소이자..

Resource Owner가 Authorization Server의 로그인 페이지에서 인증을 받고

다시 Client 페이지로 돌아갈 Client의 페이지 주소이다.

(Authorization Code는 아래에서 설명)

 

최종적으로 등록 과정에서..

Client는 Authorization Server로 부터 Client ID, Client Secret을 제공 받았고..

Authorization Server는 Client로 부터 Authorized redirect URIs를 제공 받았다.

 

 

2. 인증 과정 (Client가 Access Token을 발급 받기 까지..)

Resource Owner는 Client의 어떤 서비스를 사용하기 위해

Client는 Resource Server에 있는

Resource Owner의 Resource를 사용해야하는 상황이라고 생각해보자..

 

여기서.. 예를 들면..

Resource가 개인정보라면..

Resource Owner가 Client에 회원가입 또는 로그인을 하는 것이 될 것이고..

(넥슨이 사용자의 구글 개인정보로 넥슨에 가입을 하거나 로그인을 허용)

 

Resource가 Resource Server의 서비스라면..

Resource Owner가 Client의 서비스 중..

Client가 Resource Owner 대신.. Resource Server의 서비스를 이용해주는 것이 될 것이다.

(사용자가 넥슨 게임을 하면 넥슨이 사용자의 구글 켈린더에 사용자가 게임한 날짜를 기입)

 

다시 이어서 생각 해보자면..

Resource Owner는 Client의 어떤 서비스를 사용하기 위해

Client는 Resource Server에 있는

Resource Owner의 Resource를 사용해야하는 상황이면

Client는 Resource Owner에게 Authorization Server가 제공하는

인증(로그인) 페이지로 갈 수 있는 버튼이 있는 페이지를 보여줄 것이다.

 

해당 페이지에서 Authorization Server가 제공하는

인증(로그인) 페이지로 갈 수 있는 버튼을 누르면..

 

아래와 같은 URI로 Redirect 된다.

https://autorization.server?client_id=1&scope=B,C&redirect_uri=https://client/callback

위와 같은 URI로 Resource Owner가 Authorization Server로 요청하게 되면

Authorization Server는 Resource Owner에게 로그인 페이지를 보여주게 된다.

 

redirect uri 이므로 위 쿼리 파라미터에 있는 정보는 Client가 적재 해놓은 상태이며..

적재된 쿼리 파라미터는

Client가 알고있는 client_id와 사용할 Resource인 scope, redirect_uri가 있다.

 

Resource Owner가 로그인에 성공한다면..

Authorization Server는 요청한 URI의 쿼리파라미터의 유효성을 검증한다.

미리 Client와 Authorization Server간

약속된 Client ID와 Authorized redirect URIs가 맞는지 확인한다.

(검증에 실패하면 그대로 프로세스는 종료됨)

 

검증에 성공한다면..

Resource Owner에게 Client한테 scope에 해당되는 권한을 부여할 것인지

확인하는 창을 보여준다.

 

Resource Owner가 권한 부여를 승인한다면..

Authorization Server는 Resource Owner가 scope에 해당하는 권한을 Client에게 허용했다고 저장한다.

 

<참고>

여기서 이제..

단순하게 생각하기엔 Resource Server가 Client에게 Access Token을 발급하면 될 것 같다...

하지만.. 아니다..

해당 내용을 쭉 따라가보자..

 

계속 하자면..

Authorization Server는 Resource Owner에게

임시 토큰인 Authorization Code라는 것을 발급 및 전송한다.

 

실제 Authorization Server가 Resource Owner에게 전달하는 메시지의 Location 헤더는 다음과 같다.

(Location은 Redirect 주소로, Authorization Server가 Resource Owner에게 Redirect 하라는 주소이다.)

Location : https://client/callback?code=3

쿼리파라미터에 code라는 값이 있는데 해당 값이 바로 Authorization Code이다.

그리고, URI는 Client와 Authorization Server간 공유하고 있는

Authorized redirect URIs 이다.

 

따라서, Resource Owner는 해당 (Client)URI로 Redirect하게 되고

Authorization Code도 자동으로 Client에게 전달한 꼴이 된다.

 

다음으로..

Client는 Authorization Server에 직접 접속(요청)한다.

URI는 다음과 같다.

https://authorization.server/token?grant_type=authorization_code&code=3&redirect_uri=https://client/callback&client_id=1&client_secret=2

Client가 Authorization Server에게 Access Token을 발급 받는 요청 URI이다.

grant_type으로 authorization_code 발급 방식을 쓰겠다고 표시하였고..

code에 Resource Owner로 부터 받는 Authorization Code 값을 썻고..

redirect_uri에 미리 약속된 Authorized redirect URIs 를 썻고..

Authorized redirect URIs의 쿼리 파라미터로 Client ID와 Client Secret 값을 썻다..

 

Client에게 요청 받은 Authorization Server는

요청 URI를 보고 검증한다.

1. 해당 Authorization Code의 발급 대상이 요청온 Client ID값 과 동일한지..

2. Client ID, Client Secret, Authorized redirect URIs 값이 모두 가지고 있는 정보와 일치 하는지

 

모든 검증이 통과 된다면..

Authorization Server는 Client에게 Access Token을 응답 값으로 내려준다.

 

<참고>

Client와 Authorization Server는 임시 토큰인 Authorization Code는 삭제한다.

 

 

3. 인증 완료 후 사용 단계 (Client가 Access Token을 발급 받고 사용)

Client는 Access Token을 저장한다.

 

Client는 Access Token을 통해서

Resource Server가 가지고있는 Resource Owner의 Resource를 사용할 수 있다.

(해당 Resource는 당연히.. scope에 해당하는 권한 범위 내의 Resource 이다.)

 

Client는 Resource Server가 제공하는 API 가이드를 따라

Resource Server가 가진 Resource를 사용할 수 있다.

 

대표적으로 Google의 API 가이드에 따르면..

API에 해당하는 URI 요청 쿼리 파라미터에

access_token을 키로 Access Token을 넘겨 달라고 하고 있다.

 

또는, 요청 HTTP header의 Authorization 에 bearer로 해당

Access Token 값을 넣어달라고 가이드 하고 있다.

Authorization : bearer <Access Token>

 

참고로..

후자가 더 안전하고 권장한다.. (표준)

 

4. Access Token은 수명이 있다.

수명이 끝나면, Client가 Resource Server의 API를 사용할 수 없게 된다.

그러면 다시 Access Token을 발급받기에는 Resource Owner 에게 귀찮다..

(정책에 따라 필수로 하는 시스템도 있긴하다..)

 

그래서 나온게 Refresh Token이다.

보통..

Client에게 Authorization Server가 Access Token을 발급할 때,

Refresh Token을 같이 발급한다.

 

그래서..

Client가 수명이 다한 Access Token을 Resource Server API에 사용하면.. 

Access Token이 invalid하다고 Resource Server가 Client에게 응답으로  줄 것이다.

이때, Client는 Authorization Server에게 Refresh Token을 준다.

그러면 Authorization Server는 Client 에게 새로 유효한 Access Token을 주게된다.

(Refresh Token 도 새로 발급 하는 경우도 있음)

 

Refresh Token의 사용 과정을 그림으로 한번 보자..

 

실제로 Resource Server, Authorization Server의 세부 구현은 조금씩 다르고 사용법도 다르므로..

실제 API문서와 공식 가이드 문서를 보고 사용해보자..

다음은 구글의 가이드이다.

https://developers.google.com/identity/protocols/oauth2/web-server?hl=ko#httprest 

 

 

 

이제..

어려운 정의와 기타 알아두면 좋을 지식을 알아볼 단계이다.

 

OAuth 2.0 (Open Authorization) 에 대해 알아보자..

OAuth는 풀네임에서 알수 있듯이 인가에 대한 것이고..

인가(Authorization)를 위한 개방형 표준 프로토콜이다.

 

OAuth는 사용자가 자격 증명을 공유하지 않고도 Application에 리소스를 엑세스 할 수 있도록 함.

 

OAuth 1.0과 비교하면?

1. 기능을 단순화 하여 확장성을 고려하여 만들어짐

2. 1.0은 만들어지고나서 표준이 되었지만, 2.0은 처음 부터 표준으로 만들어짐.

3. https가 필수이다.

4. 암호화는 https에게 위임하였다.

5. 인증방식이 1가지에서 4가지로 늘었다.

6. API 서버에서 인증 서버를 분리 할 수 있도록 하였다.

 

OAuth 2.0 의 Sequence Process

쉽게 풀어 쓴 글만큼 쉽진 않지만..

아래 그림으로 정리하면서 복습 해보자

 

 

 

reference

https://www.youtube.com/watch?v=hm2r6LtUbk8&list=PLuHgQVnccGMA4guyznDlykFJh28_R08Q-

https://developers.payco.com/guide/development/start

https://www.rfc-editor.org/rfc/rfc6749