Oauth 2.0 는 무엇인가,, 알아보겠다
이전엔 보통 open api를 이용할때 토큰을 받아와서 헤더값이 넣어주는 걸
즉, 토큰값을 받아오는걸 구현한 방식이 OAuth 라고 알고있었다
이것도 맞지만 더 자세히 알아보고자 한다 :-)
OAuth 2.0은 인가를 위한 프레임워크이다
즉, 접근할 수 있는 권한을 주는 것이다.
여기서 헷갈리는 건 인증과 인가의 차이점이다.
인증은 Authentication : 본인여부를 확인 하는것
인가는 Authorization : 서비스나 시스템에 접근 할 수 있도록 권한이 주어지는것
OAuth 에는 네가지 역할이 있는데 그것은 다음과 같다.
4가지 실물
- Resource Owner (사용자,나) : 서비스 이용자
- Client (G마켓) : 서비스 제공자
- Authorization Server (네이버-매표소) : 토큰 발급 , 인가의 주체자
- Resource Server (네이버-검표하는곳) : 토큰 확인 , 리소스 접근심의 문지기
이렇게 정리 할 수 있는데,
이해할 수 있도록 설명을 덧붙이자면..
사용자가 G마켓이라는 서비스를 이용하고자 하는데
G마켓을 가입할때 직접 가입하지않고 요새 많이 이용하는 네이버,페이스북, 구글 ID로 로그인 하는걸
이용해서 가입하고자 한다
그러면 나라는 사용자는 Resource Owner이고
사용하고자 하는 서비스는 Client G마켓이다.
그리고 Authorization Server는 네이버나 인증을 도와주는 곳인데 이곳에서는 토큰만 발급해준다.
그이후, 발급한 토큰을 가지고 네이버에서 원하는 정보를 가져오는데
이 토큰을 확인하는 것이 Resource Server이다.
Grant Type (허가 유형)
- Client가 Authorization Server에게 토큰 발행을 요청하는 유형
토큰을 발행하는 과정에서 다양한 정보를 주고 받는데,
어떤 정보를 주고 받는가?를 알아보겠다
1. Client_id, client_secret
- Id와 pw 역할
2. Redirect_uri
- Client 가 authorization server에 토큰 발행을 요청할 때 브라우저를 아예 redirect하는
경우도 있다. 토큰을 발행하는 과정에서 client는 필요 시, 인가 되었을 타이밍에 redirect되어야 할
Uri 정보를 authorization server에게 넘겨준다.
3. Response_type
- Client가 authorization server에게 토큰발행 요청 했을 때, 응답을 정의 (request에 대한 response를 정의)
- 5가지 grant type중 2가지 방식에서만 사용 ( Implicit , Authorization code)
○ Implicit : client-> Authorization server 최초요청만으로 토큰 발행 : response_type 은 token
○ Authorization code는 최초 요청에 code 리턴
4. Grant_type
밑에서 자세히 설명하겠다 이건
5. Scope (optional)
- Client가 접근 가능하도록 승인된 내 리소스의 범위
- Client가 authorization server에 토큰을 발급받은 이후, Resource Server를 지나서 실제
Resource에 접근하려고 할때, client별로 접근이 가능한 리소스를 구별해놓은 정보
( 예를들어 G마켓에서 네이버로 접근할때, 전화번호만가능, 생일까지 가능 이런?)
6. State (optional)
- Sate는 csrf 공격을 막기위한 정보 ???
Grant Type 5가지
1. Authorization code
- 가장 복잡한 방식이지만 가장 범용적으로 사용
- 인가 받은 code값을 토대로 토큰을 요청하는 방식
- Authorization Server에게 토큰을 발행 받기 위해 code값을 요청하고 이 code값을
바탕으로 토큰을 발급 받는 방식
- Resonse_type = code
2. Implicit
- Client가 토큰발행을 요청하면 최초의 요청만으로 Authorization Server가 토큰 발행
- Response_type = token
- 쿼리스트링에 토큰 노출-> 모바일앱 또는 단말기에서 동작하는 웹 애플리케이션에서 주로 사용
3. Client Credentials
- 너무너무 신뢰가는 Client라서 Authorization Server가 묻지도 따지지도 않고 토큰 발행
- Resource Owner가 아닌 Client가 요청함
4. Resource Owner Password Credentials
- Resource Owner가 Client에게 id/password 전달함
- 토큰발행 요청하는 방식이 GET
- Resource Owner와 Client의 일급비밀(password/secret)을 모아서 토큰발행 요청
5. Refresh
- 최초에 token 받았을 때, 발급되는 refresh token으로 token 만료시, 재 발행 요청
- Authorization Code / Client Credentials Grant type 만 가능
