OAuth2 에 대한 정리

OAuth(Open Authorization)란? 

 인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근권한을 부여할수 있는 공통적인 수단. 접근 위임을 위한 개방형 표준.

 ex) Authorization Code Grant(일반적이 소셜로그인)

   A 사이트 접근 -> 페이스북 로그인 선택 -> 페이스북에 로그인/패스워드 입력후 인증 -> A사이트에 접근가능한 토큰 발급 -> 인증완료

 

OAuth 2.0의 특징

 1. OAuth1.0 단점.

   - OAuth1.0은 웹어플리케이션 외에는 사용이 어려웠으나 OAuth2.0 에서 앱, 데스크탑, 웹 등의 인증방식 강화

 2. 개선점

   - OAuth1.0의 인증플로우, 전반적인 목적만 공유하고 새로작성 호환X

   - 인증 절차 및 구현 간소화

   - OAuth1.0에서 사용하던 HMAC 사용 -> 암호화 관련은 https에게 맡김

 

용어 설명

 Resource Owner : 사용자

 Resource Server: REST API 서버

 Authorization Server : 인증서버

 Client: 써드파티 어플리케이션

 

Access Token 과 Refresh Token

 1. Access Token

   - 요청절차를 정상적으로 종료한 클라이언트에게 발급

   - 자원에 접근할때 권한 확인용으로 사용

   - 클라이언트에 발급된 권한의 대표(문자열 형태) 

   - 계정인증에 필요한 형태들을 표현

   - 리소스 서버는 여러가지 인증방식에 대응 하지 않아도 권한을 확인할수 있게 해줌.

   - 제한 시간이 있음.

 

 2. Refresh Token

  - Access token을 새로 발급받기위해 필요.

  - Access token 발급받을때 같이 발급.

  - token 형태는 Access Token과 동일(문자열) 

 

클라이언트 종류

  Confidential Client: 웹서버가 API를 호출하는 경우 등과 같이 client증명서(client_secret)를 안전하게 보관할 수 있는 Client

  Public Client: 브라우저 기반 애플리케이션이나 모바일 애플리케이션 같이 client 증명서를 안전하게 보관할수 없는 Client, 이런경우 redirect_uri를 통해 client 인증

 

인증방식 종류

  Authorization Code Grant

  페이스북 로그인같은 소셜 로그인에서 쓰는 방식

 

 

[출처: https://minwan1.github.io/2018/02/24/2018-02-24-OAuth/]

1. 클라이언트(Redirect Url포함) -> 인증서버에 인증요청

2. 인증서버는 유저에게 로그인창(페이스북 로그인 창 같은)을 제공

3. 인증서버 인증완료 -> 인증코드를 클라이언트에게 제공.

4. 클라이언트(인증코드) -> 인증서버에 Access Token요청

5. 인증서버가 클라이언트 서버에게 Access Token, Refresh Token 발급

6. 클라이언트 서버는 발급받은 Access Token을 가지고 Resource 서버에 자원 요청

7. Resource 서버는 클라이언트 서버에게 자원 전달

8. Access Token가지고 Resource 요청

9. Access Token에러 발생

10. Refresh Token가지고 재발급 요청

11. Access, Refresh Token 재발급

  Implicit Grant

  Public Client인 브라우저 기반의 어플리케이션이나 모바일 어플리케이션에서 바로 Resource Server에 접근하여 사용하는 방식

[출처: https://minwan1.github.io/2018/02/24/2018-02-24-OAuth/]

1. 클라이언트 -> 인증서버 인증요청
2. 유저는 인증서버를 통해 인증
3. 인증서버는 Access Token포함하여 클라이언트의 Redirect url 호출
4. 인증서버에 Access Token 검증요청
5. 인증서버에서 토큰유효성 판단후 완료되면 토큰의 만기시간과 함께 리턴해줌.
6. 발급받은 Access Token을 가지고 Resource 요청
7. Resource 서버에서 해당 자원 리턴

 

  Resource Owner Password Credentials Grant

[출처: https://minwan1.github.io/2018/02/24/2018-02-24-OAuth/]

1. User가 Id와 Password를 입력
2. 클라이언트(Id, Password, 클라이언트 정보) -> 인증서버로 넘김
3. 인증서버에서 클라리언트 서버로 Access Token, Refresh Token발급

 

  Client Credentials Grant

   어플리케이션이 Confidential Client일때 id와 secret을 가지고 인증.

[출처: https://minwan1.github.io/2018/02/24/2018-02-24-OAuth/]

1. 클라이언트 정보를 인증서버에 넘김
2. Access Token을 Client에 전달

 

  Device Code Grant

  장치 코드 부여 유형은 브라우저가 없거나 입력이 제한된 장치에서 사용

 

  Refresh Token Grant

  기존에 저장해둔 Refresh Token이 존재할때 Access Token재발급 받을 필요가 있을떄 사용, 기존엑세스는 토큰 만료.

 

 

 

 

 

참고자료:

https://minwan1.github.io/2018/02/24/2018-02-24-OAuth/

Wan Blog

http://blog.weirdx.io/post/39955

내 맘대로 OAuth 2.0 정리! - 이상한모임

https://oauth.net/2/

OAuth 2.0 — OAuth

https://digitalbourgeois.tistory.com/60

OAuth 알아보기

https://developer.accela.com/docs/construct-authCodeFlow.html

Authorization Code Flow

https://hyunalee.tistory.com/4

OAuth2.0