생활 코딩 강의 영상URL
Oahth2
여러가지 애플리케이션 기술을 이용하여 구현되는 기술
나의 서비스에 등록된 사용자의 정보를
또다른 서비스 서버에 접근하여
대신 정보를 가져오고 액션을 취한다.
접근하고자 하는 서버에서 accessToken을 발급해준다.
Resource Server : 접근하고자 하는 서버
Authorization Server : 인증 서버
Resource Owner : 사용자
Client : 나의 서비스 서버
Register
나의 서비스(Client)를 Resource Server에 등록
서비스마다 다 다르지만 공통적인 부분이 있다.
- Client ID
내가 만드는 에플리케이션의 식별자
- Client Secret
애플리케이션의 비밀번호
ID는 노출되도 상관 없지만 Scret은 절대 노출되선 안된다.
- Authorized redirect URIs
Resource Server가 권한 부여
Authorized Code를 우리가 정의한 URIs로 발급해준다.
리다이렉션 URI
- 동작 목표 : 클라이언트 사용자 > 로그인
보안 정책 설정 : 내가 설정한 URI로만 허용한다.
Resource Server(구글등)에서 로그인 실패 성공 판단
Resource Server에서 리다이렉션 URI로 로그인 결과값을 반환
결과값 = Authorized Code
Resource Server에 나의 에플리케이션 등록
- 메인 페이지에서 콘솔 페이지로 입장합니다.
- 새로운 프로젝트를 생성합니다.
- 프로젝트 이름을 지정합니다.
- 프로젝트를 선택하여 상세 정보를 수정합니다.
- 드롭다운 메뉴에서 API 서비스 메뉴로 이동합니다.
- 사용자 인증정보 OAuth 클라이언트 ID를 생성합니다.
- 먼저 동의화면을 구성합니다.
- 외부에서 접근할 수 있도록 항목을 체크합니다.
- 우리가 사용할 앱정보와, 개발자의 연락처를 작성합니다.
- 동의화면 구성이 끝나면, 다시 사용자 인증정보를 만듭니다.
- Server와 Client간에 약속된 주소를 지정합니다.
- 클라이언트키와 비밀번호를 발급받습니다.
이때 ID는 노출될 수 있지만
비밀번호는 절대 노출되어선 안되니 보안 사고에 유의합니다.
웹 프레임워크에서 사용시 환경변수를 사용하여 필히 관리하셔야 합니다.
승인되는 과정
- 현재 진행 상황
Client와 Resource Server간에 서로를 확인할 수 있는
클라이언트 아이디 비밀번호를 알게 되었다.
redirect url로 어떤 경로로 데이터를 주고 받을지 약속되었다.
- 사용자의 소셜 로그인 요청 (접근 동의)
clinet ID = 나의 웹 서비스 아이디
scope = 로그인,글작성, 결제 등등의 다양한 기능
redirect_uri = 클라이언트와 Resource server간의 약속된 주소
동작 순서
- Owner가 소셜 로그인 버튼을 클릭
- Client에서 미리 작성된 URI 제공
- Owner가 제공받은 URI로 Server에 발송
- Server가 로그인 화면 제공
- Owner가 Server에 로그인 요청
- Server는 제공받은
Client ID와 Secret,redirect url 검증- 검증에 성공한다면 server는 owner에게 client에 정보를 제공할것인지 확인하는 메세지를 전송
- owner가 server에 허용한다고 응답
- server는 user_id와 scope 기능을 허용한다는 데이터를 저장
Resource server의 승인 과정
바로 access token을 발급하지 않는다.
- server 는 authorization code를 owner에게 전송
location : redirection
Server가 리다이렉션 uri로 owner에게 이동하라 명령
- owner는 server로부터 제공받은 authorization code를 은밀하게 client에게 제공
- client가 server에 전달받은 데이터 전송
- server는 모든 데이터를 검증하고
모든 데이터가 맞다면 server는 임시 비밀번호인
authorization code를 제거
server는 accessToken을 Client에게 응답
client는 전달받은 accessToken 내부적으로 저장
accessToken은 Resource Server의 user_id의
유효한 기능에 관하여 권한이 있다는 것을 알린다.
API 호출
AccessToken을 이용하여
Resource server를 사용하기 위한 메뉴얼이 있다.
메뉴얼 = API
Application Programming Interface
Resource Server를 조작하기위한 일종의 장치
Google Calendar API
- 캘린더 리스트 GET API
https://www.googleapis.com/calendar/v3/users/me/calendarList
로그인이, AccessToken이 있어야 접근할 수 있는 URL
아래는 AccessToken을 발급 받았다 가정하에 진행한다.
https://developers.google.com/identity/protocols/oauth2/web-server?hl=ko#httprest_4- 문서의 안내에 따르면 쿼리문
즉 ?access_token = (사용자의 access_token)형태로 전달하라 보여주고 있다.
- 즉 API Reference의 양식에 맞춰 쿼리문으로
accessToken을 전달해야한다.- 그러나 문서에서 안내하는것처럼 쿼리문은 로그에 표시되는 경향이 있으므로 HTTP 헤더를 사용하는 것이 더 안전하다고 안내하고 있다.
CURL을 이용한 예시
Refresh Token
수명이 끝난 accessToken을 재발급하는 Token
The OAuth 2.0 Authorization Framework 표준 문서
A : 권한 획득
B : Access,Refresh Toekn 발급
C : AccessToekn을 제출하여 API 획득
D : 보호된 자원 획득
E : 유효기간이 지난 AceesToken 제출
F : 유효기간이 지났음을 알림
G : Refresh Toekn 제출
h : Access Token을 다시 발급받는다.
구글의 액세스 토큰 갱신
Oauth 인증 방식의 전체 흐름도
더 노력하겠습니다