의미
- 다양한 플랫폼 환경에서 권한 부여를 위한 산업 표준 프로토콜
- 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신의 정보에 대해 웹사이트나 어플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로 사용
사용 이유
다른 서비스의 회원 정보를 안전하게 사용하기 위한 방법으로 구글 계정을 이용해 다른 사이트에 접속할 때, 다른 사이트에 내 구글 아이디와 비밀번호를 알려주지 않고도 다른 서비스에서 구글 계정을 이용해 안전하게 접속과 이용할 수 있게 해주는 게 OAuth 2.0이다.
OAuth 2.0 구성
- Resource owner : 사용자
- Client : Resource Server에서 제공하는 자원을 사용하는 애플리케이션
- Resource server : 자원을 호스팅하는 서버
- Authorization server : 사용자의 동의를 받아 권한을 부여하는 서버, Resource server와 같은 url 하위에 있는 경우가 일반적임
Token
OAuth의 핵심은 Access token!
Access Token
- 위의 4가지 권한 요청 방식 모두 요청 절차를 정상적으로 마칠 경우, 클라이언트에 Access token이 발급됨
- 보호된 리소스에 접근할 때 권한 확인용으로 토큰이 사용됨
- 임의의 문자열 형태로 클라이언트에 발급된 권한을 대변함
- 계정 아이디와 비밀번호 등 계정 인증에 필요한 형태들을 토큰 하나로 표현함으로써 리소스 서버는 여러가지 인증 방식에 각각 대응 없이 권한을 확인할 수 있게 됨
Refresh Token
- Access token의 사용시간은 제한되어 있음, 유효기간 만료될 경우 새로운 Access token을 얻게 되는데 이때 Refresh token이 활용됨
- 권한 서버가 Access token과 함께 Refresh token을 발급하여 추가적인 발급 절차없이 Refresh tokendㅡㄹ 미리 가지고 있을 수 있음
- 문자열 형태이며 권한 서버에서만 활용되고 리소스 서버에는 전송되지 않음
Access Token 넘겨 받기
고객이 내 사이트를 구글 계정을 이용해 로그인 할 경우, 구글 회원임을 인증하기 위해 구글 로그인 페이지로 이동하여 구글 서버에서 아이디와 비밀번호를 확인하고 구글은 이 고객과 관련된 Access token을 발급한다.
인증종류
- Authoriztion Code Grant
- Implicit Grant
- Recource Owner Password Credentials Grant
- Client Credentials Grant
Authoriztion Code Grant
- 서버사이드 코드로 인증하는 방식
- 권한 서버가 클라이언트와 리소스 서버 간의 중재역할
- Access Token을 바로 클라이언트로 전달하지 않아 잠재적 유출을 방지
- 로그인시에 페이지 url에 response_type=code라고 넘김
Implicit Grant
- token과 scope에 대한 스펙 등은 다르지만 OAuth 1.0a와 가장 비슷한 인증방식
- public client인 브라우저 기반의 어플리케이션이나 모바일 어플리케이션에서 이 방식을 사용하면 됨
- OAuth 2.0에서 가장 많이 사용되는 방식
- 권한 코드 없이 바로 발급되어 보안에 취약
- 주로 read only 서비스에 이용
- 로그인시 페이지 url에 response_type=password라고 넘김
Password Credentials Grant
- Client에 아이디/패스워드를 저장해 놓고 직접 access token을 받아오는 방식
- Client를 신뢰할 수 없을 때는 사용하기 위험
- 로그인시 api에 POST로 grant_type=client_credentials라 넘김
Client Credentials Grant
- 어플리케이션이 confidential client일 때, id와 secret을 가지고 인증하는 방식
- 로그인시에 api에 POST로 grant_type=client_credentials라 넘김
실습하기
참고자료 : 생활코딩
구글 캘린더 OAuth 리디렉션 실습!
console.cloud.google에 접속
Google Cloud Platform 옆에 OAuth prac이라고 떠있는 부분 클릭
새 프로젝트 생성
API 및 서비스 메뉴로 들어와서
OAuth 클라이언트 ID를 생성!
Google Calendar API 사용을 허용하고
가이드 및 문서 부분의 Calendar API Reference 클릭
해당 메뉴로 들어가면 우리는 허용 범위를 정하기 위해 Scope 부분이 필요함!
다른 탭을 열어서 google api oauth로 검색할 경우 구글 디벨롭퍼 사이트가 나옴
우리는 server-side web apps의 HRRP/REST url을 이용할 계획
해당 내용을 복사해서 간단한 실습 파일 생성
우리는 이 두가지 범위 모두 사용할 계획이나 두 url을 합칠 필요가 있음
URL encoder 사용 : https://meyerweb.com/eric/tools/dencoder/
여기까지하고 웹 로컬호스팅하는 방법을 모르겠어서 다음 시간에 계속....
아래 내용은 개인적으로 공부하던 끄적거림... 나중에 지우겠습니다..
Authoriztion strategies
Session ID
reference token
cookies
save it in cookies is the most common
problem
1.
JWT (json web tokens)
value token
http
http is stateless protocol
every interaction in http needs to contain all the information needed for the intraction. no more state for multiple intraction
structure
참고자료
header, payload, verify signature
