OAuth

직접 서버에서 인증과 관련된 로직을 처리하지 않고 인증을 중개하는 외부 서버를 이용하는 기술
사용자 입장에선 자주 사용하고 중요한 서비스만으로 외부 서비스를 이용할 수 있어 편리함
개발자 입장에서도 신규 회원가입이나 회원 관리를 신경 쓰지 않아도 되기 때문에 선호함
검증되지 않은 App도 OAuth를 사용해 로그인하면 민감한 정보가 직접 노출되지 않아 보안상의 이점이 있음

작동 메커니즘

주체

Resource Owner 사용자

OAuth 인증을 통해 소셜 로그인을 하는 사람
Resource : 사용자의 이름, 전화번호 등의 정보

Resource Server & Authorization Server 사용중인 서비스

Resource Server : 사용자가 소셜 로그인을 하기 위해 사용하는(이미 사용중인) 서비스의 서버 중 사용자의 정보를 저장하고 있는 서버
Authorization Server : 이미 사용중인 서비스의 서버 중 인증을 담당하는 서버

Application 새로운 서비스

사용자가 소셜 로그인을 활용해 이용하고자 하는 새로운 서비스
(환경에 따라 다르게 불릴 수 있음)
경우에 따라 Client와 Server로 세분화해 지칭하기도 함

인증 방식의 종류와 흐름

OAuth의 인증 방식에는 여러 종류가 있음

Implicit Grant Type	Authorization Code Grant Type	Refresh Token Grant Type
사용자 사이트 접속 ↓ Application 인증 요청 ↓ Authorization Server 인증 확인 Access Token 전달 ↓ Application Access Token 전달 ↓ Resource Server 액세스 토큰이 유효한 토큰인지 확인 유효한 토큰일 경우 사용자 정보 전달 ↓ Application	사용자 사이트 접속 ↓ Application 인증 요청 ↓ Authorization Server 인증 확인 Authorization Code 전달 ↓ Application Authorization Code 전달 ↓ Authorization Server Authorization Code 확인 Access Token 전달 ↓ Application Access Token 전달 ↓ Resource Server Access Token 확인 사용자 정보 전달 ↓ Application	사용자 사이트 접속 ↓ Application Refresh Token 전달 ↓ Authorization Refresh Token 확인 Access Token 전달 ↓ Application Access Token 전달 ↓ Resource Server Access Token 확인 사용자 정보 전달 ↓ Application
기존 서비스에 로그인만 되어있다면 새로운 서비스에서 바로 액세스 토큰을 내어주기 때문에 보안성 문제가 있음 (잘 사용되지 않음)	Authorization Code를 사용한 인증 단계가 추가로 존재 (더 안전함) AuthServer과 LocalServer 사이에만 AccessToken이 오가는 방식으로 Client에 토큰을 노출시키지 않는 방법도 사용 가능함	리프레시 토큰을 사용 액세스 토큰을 받아오는 방식 (매번 액세스 토큰을 발급받지 않아도 되기 때문에 사용자 경험이 더 좋음)

장점

쉽고 안전하게 새로운 서비스 이용 가능

• 사용자 입장에서 일일이 개인정보를 입력하지 않고 가입, 서비스를 이용할 수 있음
• 정보를 직접 노출하는 것이 아니기 때문에 더 안전함
• 개발자측에서 정보를 직접 다루지 않아 유출의 위험성에서 부담이 줄어듬

권한 영역 설정 가능

• 사용자는 원하는 정보에만 접근을 허락할 수 있음