접근 권한 위임과 OAuth
접근 권한 위임
한 서비스가 다른 서비스에 있는 보호된 리소스에 대한 접근 권한을 위임하거나 받는 기능
A사이트에 있는 내용들을 B사이트로 옮기고 싶은 경우
- 방법 1: 사용자가 직접 옮기기 -> 비효율적
- 방법 2: 데이터를 받아오려는 사이트에게 데이터를 가지고 오려는 서비스에 대한 유저인증 정보를 넘겨주기
하지만 아이디와 비밀번호를 제공할 경우 위험할 수 있다.
이 문제를 해결하기 위해 유저의 인증정보(이메일, 비번 같은)를 다른 사이트에 제공하지 않고도 접근 권한을 위임할 수 있는 OAuth(Open Authorization)이 만들어졌다.
OAuth
주체와 설정
코드잇 사이트에 스케쥴링 기능을 추가한다고 할 때 유저들이 손쉽게 관리할 수 있게 구글 캘린더와 연동해서 저장된 일정들을 가져오고, 새롭게 만든 일정을 보내고 싶은 상황
이 상황에서 인가 서버는 구글, 리소스 서버는 구글 캘린더이다.
인가 서버에서는 코드잇 고유의 client id, secret 값을 받는다.
리퀘스트가 코드잇에서 온다는 것을 증명하기 위해서 필요한 값들
Scope: 인가서버로부터 넘겨 받으려는 권한의 범위
작업과 관련된 권한만 받을 수 있다.
워크플로우
특정 목표를 이루기 위한 작업 흐름
OAuth 워크플로우: 접근 권한을 특정 방식으로 주고 받기 위해서 각 주체들이 해야 되는 작업들과 그 순서
사진 출처: 코드잇
Authorization Code : 유저 본인이 권한 위임을 원하다는 걸 확인시켜주는 데이터
토큰을 사용하다 만료되면 워크플로우의 가장 앞 단계부터 모든 단계를 따르면 된다.
OpenID Connect (OIDC)
OAuth에 인증까지 포함시킨 표준 (소셜로그인 같은 것)
OIDC 프로바이더 (인증을 대신 해주는 서비스)
워크 플로우
- OpenId 프로바이더에서 고유의 client id, client Secret 값을 발급받는다. 이 두 값은 백엔드에 저장
- Scope 설정
이것을 하면 OIDC 프로바이더를 사용할 수 있다.
사진 출처: 코드잇
다양한 OAuth/OpenID 플로우
위에 적은 플로우는 가장 많이 사용되고 권장되는 Authorization Code 플로우이다.
Implicit 플로우
- 인가 서버에서 OAuth를 쓰기 위한 설정을 한다. 위임받으려는 권한의 범위 Scope를 설정하고 Client ID와 Secret을 발급받는다.
- 프론트엔드는 유저에게 인가 서버로부터 권한을 위임해달라고 요청, 그러면 유저는 이메일과 비밀번호를 사용해서 구글에게 신원 증명
- 신원이 증명되면 Authorization Code 플로우에서는 프론트엔드에게 authorization code를 발행해 주는데, Implicit 플로우에서는 access token 자체를 리턴 받는다. OpenID Connect를 사용하고 있다면 여기서 바로 id token을 리턴받음
- 프론트엔드는 이걸 다시 백엔드로 전달하고, 백엔드는 이걸 사용해서 리소스 서버에 접근
Implict 플로우를 사용하면 이전보다 훨씬 더 간단하게 OAuth를 사용할 수 있는데 Authorization Code 플로우가 권장되는 이유
안정성 때문!
access token을 갖고 있으면 리소스 서버에 여러 작업들을 요청할 수 있고, id token은 유저의 개인 정보를 담고 있기 때문에 믿을 수 없는 사람에게 유출되면 안 되는데, Implicit 플로우를 사용하면 access token이 클라이언트 코드와 브라우저, 그리고 브라우저가 실행되고 있는 개인 컴퓨터에까지 노출되기 때문에 중간에 누군가가 가로챌 수 있는 가능성이 있다.
프론트엔드에 저장된 정보는 백엔드 서버에 저장하는 것과는 달리 노출되기가 쉽기 때문에 Client Secret과 같이 민감한 정보를 저장하고 사용할 수 없다.
Authorization Code를 사용하면 프론트앤드는 Authorization code만 갖고 있고, Client Secret은 오직 백엔드 서버에만 저장되어 있다.
Authorization code의 유일한 기능은 인가 서버에 보내서 access나 id 토큰을 발행 받는 것이다.
이때 Client ID와 Secret을 함께 보내야 하는데, 이 두 데이터는 프론트앤드에 저장하지 않기 때문에 누군가 악의를 갖고 클라이언트 쪽에서 Authorization Code를 가로챈다고 해도 사용할 수 없다.
오직 인가 서버와 백앤드 서버만 알고 있는 Client ID와 Secret을 사용하면, 항상 믿을 수 있는 사이트에만 민감한 데이터인 access와 id token을 보낼 수 있다.
이런 문제가 생길 수 있기 때문에 OAuth를 사용할 때는 조금 더 간단한 Implicit 플로우보다, 번거로운 Authorization Code 플로우를 사용하는 게 권장된다.
