시작에 앞서

본 내용은 "생활코딩 oAuth2.0"을 보고 작성한 내용으로, 이미지와 코드는 해당 강좌에서 포함 된 것입니다.
개발공부를 처음 하기 때문에 단어사용와 의미출처에서 오류가 있을 수 있습니다. 수정사항은 댓글로 부탁드립니다.

지난 글에서

client가 Resource Owner의 승인을 얻는 과정을 설명했습니다.
이로써 client가 Resource Owner 대신해 로그인 할 수 있을까요?

아닙니다!

아직 Resource Server로 부터 승인을 받지 않았기 때문입니다.

Resource Server는 client가 누구인지 확신할 수 없습니다.###

그럼 어떻게 Resource Server는 client를 확인할까요?

임시 비밀번호를 전달하는 Resource Server

이미 client는 Resource Owner로 부터 로그인과 모든 기능(scope)을 사용 할 수 있다는 허락을 받았습니다.

그럼 이제 어떻게 Resource Server로 부터 승인을 받을 수 있을까요?

그 핵심은 임시번호인 Authorization code 입니다.

여기에서 가장 첫 단계에서 사용자가 개발자 홈페이지에 입력한 콜백함수, 즉Authorized redirect URIs가 등장합니다.

https://client/callback

해당 콜백함수는 client를 판별하는 수단이 되기도 합니다.

Resource Server는 "code=3" 이라는 Authorization code를
콜백함수(client가 설정한)에 포함합니다.

https://client/callback&code=3

그리고 이것을 Resource Owner 브라우저에게 전달합니다.

이말인 즉슨,
Resource Server가 Resource Owner 웹 브라우저에게 저 주소로 이동하라는 명령입니다.
그러면 Resource Owner의 브라우저는 Location 헤더 값의 의해서 위 주소로 이동합니다.

이동(Redirect)할 수 있는 것은 Location 때문입니다.

그렇게 은밀하고 조용하게 Resource Owner를 통해서 Authorization code(code=3)가 client에 전달되게 됩니다.

이를 통해, client는 Resource Server가 보낸 Authorization code, "code=3"를 Resource Owner통해 받습니다.###

쉬어가기..

현재까지 client와 Resource Server의 상태는 다음과 같습니다.

client와 Resource Sever는 각각 다음의 정보를 갖습니다.

client

Client id, Client Secret , autthorization code

Resource Sever

Client id, Client Secret , Redirect URL, authorization code, userId, scope

client

1. Client id : 클라이언트의 id
2. Client Secret: 클라이언트의 Password
3. authorization code : Resource Ownder의 권한을 위임받은 해당 클라이언트를 식별하는 식별자

Resource Sever

1. Client id : 클라이언트의 id
2. Client Secret : 클라이언트의 Password
3. Redirect URL : 해당 클라이언트를 식별하고 식별값(Access token)을 전달할 통로
4. authorization code : Resource Sever가 전달하는 임시 비밀번호
5. userId : 클라이언트와 관련있는 해당 Resource Owner를 식별하는 식별자
6. scope : 해당 Resource Owner가 Resource Sever에서 사용할 기능들

내가 그 client 이란 걸 증명하겠소!

비로소 client가 "그 client"라는 걸 말할 타이밍 입니다.
client는 자신이 가진 정보를 바탕으로 아래의 링크를 Resource Server에게 전달합니다.

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

위 코드를 통해 자신이 그 client 라는 이유를 해당 정보를 포함함으로써 하나씩 말하고 있습니다. 그 이유는 아래와 같습니다.

1. authorization_code&code=3

Resource Server가 해당 Resource Owner를 통해 전달한 값(code=3)을 받았다고 말합니다.

2. redirect_uri=https://client/callback

client(개발자,application)가 개발자 홈페이지에 해당 콜백을 넣었다는 것을 증명합니다.

3. &client_id=1

자신이 Resource Owner의 권한을 위임받은 그 client라는 사실을 밝힙니다.

4. client_secret=2

개발자 홈페이지에 해당 client에게만 발행되는 비밀번호인 secret 번호는 "그 client"만 알고 있기 때문입니다.

당신이 그 client 였군요!, 여기 "이것"을 받으세요,

Resource Server는 client가 보낸 코드를 통해 드디어 진정한 client를 만나게 됩니다.

이를 통해 "드디어" client는 Resource Server에 접속 할 수 있게 됐습니다.

확인의 증표로 Resource Server는 client는 "Access token"을 줍니다.##

이제 client는 "Access token"을 보유하게 됐습니다.###

Resource Owner의 정보를 사용할 수 있게 됐습니다

이제 client는 Resource server의 api를 이용해(요청해) Resource Owner의 ID 혹은 프로필 정보를 사용할 수 있게 됐습니다.

마무리,,

핵심징표인 "Access token"을 받기 위해 여러 과정을 달려왔습니다.
삼자관계에서 누가누구인지 알아야 하기 때문에 복잡하지 않나 확인 과정이 많지 않나 생각합니다.

하지만 그에 대한 이점은 분명 있습니다.
Resource Owner는 불편한 로그인 입력과정을 간편하게 할 수 있게 되었고,
client는 사용자의 개인정보를 저장하지 않아도 됩니다.
마지막으로 Resource Server 자사 서비스 api 안으로 유저와 클라이언트를 묶어둬 자기 영역안에서만 활동하게 만들었습니다.

다음 편에서는 "Access token"에 대해서 다루겠습니다.