OAuth 인증 과정

목차

 

 

저번에 프로젝트에서 구글 로그인과 구글 드라이브에 있는 파일들을 공유하는 기능을 구현했고, 이때 OAuth를 사용해 회사의 서비스가 구글에 접근할 수 있는 권한을 얻게 되었다. OAuth의 원리에 대해 공부를 딥하게는 하지 못한채로 프로젝트를 끝낸것 같아 글로 정리하고 세미나를 진행해보기로 했다.

 

OAuth를 설명하기 이전에 왜 OAuth를 사용해 다른 서비스에 접근하는 권한을 획득하는 방법을 사용하는지에 대해 생각해봤다. 사실 그냥(google을 예로 들겠다) ID/PW를 우리의 서비스에 저장한 채로 구글에 보내 접근 권한을 획득하는 것이 루트도 짧고 편하지만, 사용자는 자신의 아이디와 비밀번호와 같은 개인정보를 처음보는 서비스에 맡기기에는 부담이 있다. 또한 우리 회사의 입장에서 노출되면 안되는 개인정보를 관리하는 것은 부담이 있고, 구글과 같은 회사의 입장에서도 자신의 고객들이 위험에 노출되는 것을 원치 않을 것이다. 

 

이러한 위험성 때문에 OAuth를 사용하여 사용자는 서비스에 접근하는 권한을 획득한다. OAuth를 사용하면 access token을 얻을 수 있고, ID/PW가 아닌 access token을 통해 권한을 획득할 수 있기 때문이다. 

 

 

역할

---

먼저 계속 언급될 주체들과 그 역할에 대해 알아야 한다. 

 

• Resource Owner(user)
• Client(우리의 서비스)
• Resoure Server(google과 같은 다른 서비스 자원, 데이터), Authorization Server(google과 같은 다른 서비스 자원, 인증)

---

그럼 이제 본격적으로 유저가 우리의 웹 서비스에서 구글 드라이브 권한을 얻기위해 OAuth 2.0을 통해 권한을 획득하는 과정에 대해 알아보자.

 

 

1. 등록 (client가 resource server에 등록)

---

resource server는 client로부터 아래의 3가지 값을 받는다. 

1. client ID (애플리케이션 식별자)

2. client secret (애플리케이션 비밀번호)

3. authorized redirect urls (authorized code를 받는 주소)

 

등록을 하고 나면 client와 resource server는 client에 대한 정보(client ID, client secret)와 redirect url을 알게 된다. 

 

 

2. 인증-Resource Owner의 승인 (사용자가 resource server에 접속하는데 동의를 구하는 과정)

---

1.  resource owner가 client에 접속

2.  접속하는 과정 중 resource owner가 resource server에 접근이 필요한 경우 client에 login 화면 노출

출처: 생활코딩

3. resource owner가 버튼 클릭 시 사전에 생성해둔 아래와 같은 url로 이동(resource server로 접속)

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

 

4. resouce server는 resource owner의 로그인 여부 파악

5. 로그인이 되어 있지 않으면 로그인 화면 노출

6. 로그인 성공 시 resource server는 client_id 값과 redirect url 값의 일치여부 확인

7. 일치한다면 resource server는 resource owner에게 scope에 해당하는 권한을 부여할 것인지 확인하는 화면 노출

8. resource owner가 권한 허용 시 resource server는 user_id와 scope에 대한 정보를 서버에 저장

 

 

3. 인증-Resource Server의 승인

---

1. resource server는 authorization code(임시 비밀번호)를 resource owner에게 전송

https://client/callback?code=3

2. location header 값에 의해 위 주소로 이동

3. client는 authorization code의 값을 알게됨

4. client는 resource server로 직접 접근(authorization_code, client_secret)

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

5. resource server는 authorization code를 비교하여 값의 일치여부 확인(client id, client secret, redirect url...)

 

 

4. resource server 엑세스 토큰 발급

---

1. resource server와 client는 authorization code를 제거한다. (다시 재인증하지 않기 위함)

2. resource server는 access token을 발급하고, client에게 전달한다. 

3. client는 acess token을 내부에 저장한다. 

 

 

5. API 호출

---

access_token을 query에 추가하여 호출하는 방법 또는 Authorization: Bearer를 HTTP header에 추가하여 호출하는 방법이 있다. 공식문서에서는 HTTP header에 추가하는 방식을 더 선호한다고 한다. 

 

 

6. refresh token

---

access token은 만료 기한이 있다. 만료 기한이 지나면 다시 access token을 받아야하는데 그때마다 사용자를 다시 로그인 시키는 것은 UX에 좋지 않다. 이때 사용하는 것이 refresh token이다. 

 

사용자가 로그아웃하지 않았다면 새로운 access token이 담긴 JSON 객체를 반환한다. 

{
  "access_token": "",
  "expires_in": 3920,
  "token_type": Bearer
}

 

 

 

참고자료

---

• 생활코딩 OAuth 2.0