OAuth2.0 개념과 동작에 대해 알아보자

목차

1. OAuth란?

2. 등록

   2-1. 구글 등록 테스트

3. OAuth 2.0 Flow

1. OAuth란?

• OAuth(Open Authorization)

• 인가 프레임워크는 리소스 소유자와 HTTP 서비스 간의 승인 상호 작용을 조정하거나 타사 응용프로그램이 자체적인 액세스를 획득하도록 허용함으로써 타사 응용 프로그램이 리소스 소유자를 대신하여 HTTP 서비스에 대한 제한된 액세스를 얻을 수 있도록 해준다.

• 위 그림과 같이 구글, 페이스북, 네이버 로그인 같은 소셜 로그인들은 OAuth2 프로토콜 기반의 인증방식을 지원한다.

• 연동되는 외부 웹 어플리케이션에서 페이스북과 트위터 등이 제공하는 기능을 간편하게 사용할 수 있다.

• 즉, OAuth는 다른 서비스의 회원정보를 안전하게 사용하기 위한 방법이라고 생각하자.

• 사용자가 자신의 소셜 아이디/비밀번호를 우리 서비스에 알려주지 않아도, 고객의 정보를 우리 서비스에서 안전하게 사용하기 위한 방법이다.

2. 등록

• 서비스마다 등록하는 방법이 모두 다르지만 공통적인 것은 아래 그림과 같다.

• Client ID
  • 우리가 만든 Application을 식별하는 식별자

• Client Secret
  • 외부에 절대 노출되서는 안된다

• Authorized redirect URIs
  • Resource Server만 갖는 정보로, client에 권한을 부여하는 과정에서 나중에 Authorized code를 전달하는 통로다.

2-1. 구글 등록 테스트

• https://console.cloud.google.com/

• 위 사이트를 접속해서 만들어보자.

• 내프로젝트에 새프로젝트를 만들어준다.

• 다음과 같이 새프로젝트이름을 지정하고 만들기를 클릭한다.

• 햄버거 박스를 눌러 API 및 서비스 > 사용자 인증 정보를 클릭한다.

• 사용자 인증 정보 만들기에 OAuth 클라이언트 ID를 클릭해준다.

• 애플리케이션 유형과 이름을 정해서 만들기 버튼을 클릭한다.

• 초반에 나온 그림 처럼 클라이언트 ID와 비밀번호(Secret)가 생성되며 Authorized redirect URIs 것을 볼 수 있다.

3. OAuth 2.0 Flow

1. 사용자(Resource Owner)는 서비스(client)를 이용하기 위해 로그인 페이지에 접근한다.

2. 그럼 서비스(client)는 사용자(Resource Owner)에게 로그인 페이지를 제공하게 된다. 로그인 페이지에서 사용자는 "페이스북/구글 으로 로그인" 버튼을 누른다.

3. 만일 사용자가 Login with Facebook 버튼을 클릭하게 되면, 특정한 url 이 페이스북 서버쪽으로 보내지게 된다.

• gitlab 사이트에서 구글 로그인을 할때 url을 복사해서 내용을 확인했을때 아래와 같다

https://accounts.google.com/o/oauth2/auth/identifier?access_type=offline&
client_id=805818759045-aa9a2emskmnmeii44krng550d2fd44ln.apps.googleusercontent.com&
redirect_uri=https://gitlab.com/users/auth/google_oauth2/callback&
response_type=code&
scope=email profile&
state=79d206dc2e07b33197ca9e4c13f15876856ba488a570dde9&
service=lso&
o2v=1&
flowName=GeneralOAuthFlow

• 향후 redirect_uri 경로를 통해서 Resource Server는 client에게 임시비밀번호인 Authorization code를 제공한다.

4. 클라이언트로부터 보낸 서비스 정보와, 리소스 로그인 서버에 등록된 서비스 정보를 비교한다.

4-1. 확인이 완료되면, Resource Server로 부터 전용 로그인 페이지로 이동하여 사용자에게 보여준다.

5. ID/PW를 적어서 로그인을 하게되면, client가 사용하려는 기능(scope)에 대해 Resource Owner의 동의(승인)을 요청한다.

5-1. 사용자가 허용 버튼 누르면 사용자는 권한을 위임했다는 승인이 Server 에 전달된다.

허용한 사용자의 user id를 1이라고 칭한다면 서버는 이와 같은 정보를 가지게 된다.

1. Client Id : Resource Owner와 연결된 client가 누군지
2. Client Secret: Resource Owner와 연결된 client의 비밀번호
3. Redirect URL : (진짜)client와 통신할 통로
4. user id : client와 연결된 Resource Owner의 id
5. scope : client가 Resource Owner 대신에 사용할 기능들

6. 하지만, 이미 Owner가 Client에게 권한 승인을 했더라도 아직 Server가 허락하지 않았다. 따라서, Resource Server 도 Client에게 권한 승인을 하기위해 Authorization code(임시 비밀번호)를 Redirect URL을 통해 사용자에게 응답하고

7. Owner는 서버에게 받은 Location 헤더 값을 통해 url을 이동하고 클라이언트는 Authorization Code를 얻게 된다.

8. 이제 Client가 Resource Server에게 직접 url(클라이언트 아이디, 비번, 인증코드 등)을 보낸다.

9. 그럼 Resource Server는 Client가 전달한 정보들을 비교해서 일치한다면, Access Token을 발급한다. 그리고 이제 필요없어진 Authorization code는 지운다.

10. 그렇게 토큰을 받은 Client는 사용자에게 최종적으로 로그인이 완료되었다고 응답한다.

11 ~ 14. 이제 client는 Resource server의 api를 요청해 Resource Owner의 ID 혹은 프로필 정보를 사용할 수 있다.

15. Access Token이 기간이 만료되어 401에러가 나면, Refresh Token을 통해  Access Token을 재발급 한다.

• Refresh Token
  • Refresh Token의 발급 여부와 방법 및 갱신 주기 등은 OAuth를 제공하는 Resource Server마다 상이하다
  • Access Token은 만료 기간이 있어, 만료된 Access Token으로 API를 요청하면 401 에러가 발생한다. Access Token이 만료되어 재발급받을 때마다 서비스 이용자가 재 로그인하는 것은 다소 번거롭다.
  • 보통 Resource Server는 Access Token을 발급할 때 Refresh Token을 함께 발급한다. Client는 두 Token을 모두 저장해두고, Resource Server의 API를 호출할 때는 Access Token을 사용한다. Access Token이 만료되어 401 에러가 발생하면, Client는 보관 중이던 Refresh Token을 보내 새로운 Access Token을 발급받게 된다.

참고

• https://opentutorials.org/course/3405

• https://inpa.tistory.com/entry/WEB-📚-OAuth-20-개념-💯-정리

• https://tecoble.techcourse.co.kr/post/2021-07-10-understanding-oauth/