Oauth 2.0 기본

1. Oauth란?

• 우리 서비스에 접속한 유저가, 우리 서비스와 연동하여 다른 서비스(ex, Google, Naver 등)의 어떠한 것(ex, 로그인, 일정 등록 등)을 사용할 때, 유저의 아이디와 비밀번호를 직접 사용하는 것이 아니라, 다른 서비스에서 발급해주는Access Token을 발급 받아서 한정된 곳에 사용하는 기술개념.

2. Oauth에 등장하는 역할

• 역할에서의 기준점은 바로 Access Token!

1. Resource Owner

   • 우리의 서버에 접속한 유저.
   • 우리 서비스와 연동하여 다른 서비스의 어떠한 것을 사용할 유저.
   • 해당 유저의 정보가 Access Token으로 발급되기 때문에 Resource Owner라고 부름.

2. Client

   • 우리의 서비스.
   • 우리는 우리의 서버에 접속한 유저의 정보를 가지고 Access Token을 발급 받아야 하기 때문에, 해당 상황에서는 우리가 Client가 된다.

3. Resource Server

   • 우리 서비스와 연동된 다른 서비스.
   • 유저의 정보를 가지고 Access Token을 발급 해주는 주체.
   • 공식 문서에는 Authorization Server가 등장하는데, 이는 인증과 관련된 처리를 전담하는 서버이며 Resource Server는 유저의 정보를 가지고 있는 서버를 이야기함. -> 따라서 명확하게는 구분될 수 있지만, 개념상으로는 다른 서비스라고 볼 수 있음. 해당 포스트에서는 구분하지 않고 Resource Server를 사용함.

3. 절차

1) 등록(Register)

• 나(우리)를 연동할 서비스에 등록하는 절차. (ex, 우리는 앞으로 로그인 할 때 google 너희의 유저정보를 연동하여 사용하고 싶어, 우리 서비스를 등록해줘)
• 개발자 페이지에서 보통 진행할 수 있음.
• 등록에 기본적으로 필요한 3가지 요소
  • Client ID- 우리 서비스를 식별하는 ID
  • Client Secret - 우리 서비스의 비밀번호
  • Authorized redirect URIs - 토큰을 받을 때 필요한 Authorization Code를 Resource Server가 우리에게 전달하게 되는데, 그 코드를 받을 URI를 적는 곳.

2) 인증(Authorization)

1. Client의 사전 작업

• 등록 절차를 마친 후, Authorized redirect URIs의 페이지를 만들어놓아야 함.

2. 인증 처리절차

1. Resource Owner가 Client가 구현해놓은 서비스에 접속하여 다른 서비스와 연동되는 기능을 사용요청 한다.

2. Client는 Resource Owner에게 아래와 같은 URI로 접속을 유도하여 다른 서비스에서 Authorization Code을 발급하게 해 줄 것을 요청함.

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

   여기서 scope는 연동하여 사용하고자 하는 기능. 즉, 권한을 얻고자 하는 기능에 대한 내용.

3. Resource Owner는 URI를 통해 Resource Server에 접속하여 로그인 한 후 주소와 같은 Client_id를 가진 서비스에게 scope에 대한 서비스를 이용할 것이라고 알리게 된다.

4. Resource Server는 scope에 대한 정보를 취득한 후 Authorization Code를 헤더에 담아 Resource Owner를 아래 주소와 같이 리다이렉트 시킨다.

   https://client/callback?
   code=3
   

   여기서 사용되는 uri가 바로 등록 시 입력한 redirect URI가 된다.

5. Resource Owner는 리다이렉트를 통해 Client에게 Authorization Code를 Client에게 전달하게 된다.

6. Client는 전달받은 Authorization Code를 추가하여 아래와 같은 URI로 Resource Server에 client_id, client_secret, Authorization Code를 전달한다.

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

7. Resource Server는 전달받은 3가지 요소를 확인하여, 서버가 가지고 있는 정보와 일치하게 되면 Access Token을 발급해준다.

간단하게 비유로 정리하면 아래와 같다.

- 유저: 내가 방금 기록한 내용을 구글 캘린더에도 저장하고 싶어
서비스: 그러면 여기(https://~~~)로 가면 구글이 도와줄거야
(유저 이동)
구글: 누구니?
- 유저: 나(로그인)
구글: 저 서비스에서 캘린더 기능 사용하고 싶어서 온거 맞아?
- 유저: 응
구글: 그럼 저기로 가봐(https://~~~)
(구글은 유저 등에 코드를 붙여준다 -> 리다이렉트)
- 유저: 여기가 맞나?
(서비스는 도착한 유저 등 뒤의 코드를 보고 구글한테 간다)
(구글은 서비스가 코드를 잘 본 것을 확인하고 유저 아이디의 접근권한을 서비스에게 준다)
서비스: 잘 왔어, 이제 캘린더 볼 수 있어

3. Client의 Resource Server API 호출

• 요청에 Access Token을 추가하여 요청하면 되며, 방법은 서비스가 API Docs 등을 통해서 제공함.
  1. Parameter에 쿼리스트링으로 Access Token을 넣어 보내는 방법
     • 보안적으로 취약하기 때문에 선호되지 않으며, 제공하지 않는 서비스도 있음.
  2. HTTP 요청에 Authorization: Bearer 이후 Access Token을 넣어서 보내는 방법.
     • 후자가 더 많이 선호되고 좋기 때문에 일반적임.

4. Refresh Token

• Access Token을 새로 발급받을 때 사용하는 토큰.
• Access Token으로 요청을 했는데, 토큰의 유효기간이 다 되었을때 그 때마다 유저에게 다시 요청을 하는 것은 번거로운 일이기 때문에 해당 개념을 사용함. -> 이는 JWT에서 사용하는 방식과도 비슷한 개념.
• 처음 Access Token을 발급받을 때 함께 발급해주기도 함.
• Refresh Token을 서비스가 요청하는 방법대로 보내면 서비스는 다시 Access Token을 발급해줌.

---

마지막 수정일시: 2022-12-04 01:10