위임
접근 권한 위임과 OAuth
- 접근 권한 위임
- 한 서비스가 다른 서비스에 있는 보호된 리소스에 대한 접근 권한을 위임하거나 받는 기능
- OAuth(Open Authorization)
- 유저의 인증 정보를 다른 사이트에 제공하지 않고도 접근 권한을 위임할 수 있는 것
- 개방형 접근 권한 위임 표준
- 이메일과 비밀번호 같이 민감한 인증 정보를 제 3자에게 넘겨주지 않으면서 제 3자가 보호된 리소스에 접근할 수 있게 해주느 절차
OAuth 주체와 설정
- 주체
- OAuth 서버 사용 전 인가 서버에서 해야 하는 설정
- 인가 서버에서 Client ID와 Client Secret이라는 값 받기
- 코드잇을 구글 인가 서버에 회원가입 시킨다고 생각하면 됨
- 접근 권한 위임을 받으려는 서비스 중 코드잇을 특정 짓고 리퀘스트가 코드잇에서 온다는 걸 증명하기 위해서 필요한 값들임
- 이 값들은 코드잇 백엔트 서버에 미리 저장해 놓음
- Scope 정하기: 인가 서버로부터 넘겨받으려는 권한의 범위
- 유저 입장에서는 스코프가 너무 넓게 설정된 서비스에는 권한을 위임해주면 안 되고 서비스 입장에서는 필요한 최소한의 권한을 미리 설정해 놓는 것이 중요함
OAuth 워크플로우
- 워크플로우: 특정 목표를 이루기 위한 작업 흐름
- OAuth 워크플로우: 접근 권한을 특정 방식으로 주고 받기 위해서 각 주체들이 해야되는 작업들과 그 순서
- Authorization Code: 유저 본인이 권한 위임을 원한다는 걸 확인시켜주는 데이터
- OAuth 2.0: 조금 더 개선 된 버전
OpenID Connect
- OpenID Connect(OIDC)
- 접근권한을 위임하는 게 아니라 인증을 하고 싶을 때 사용함
- OAuth에 인증까지 포함시킨 표준
- 한 사이트의 아이디로 여러 사이트에서 인증받기 위해 사용함
- OIDE를 따른다는 건 자동으로 OAuth를 따른다는 말임
- 주체
- OIDC 사용 전에 Open ID provider에서 해야 하는 설정
- Client ID와 Client Secret을 발급 받기
- 그 후 두 값을 코드잇 백엔트에 저장하기
- 스코프 설정: 어떤 데이터나 기능들에 접근하고 싶은지 정하기
- 워크플로우
- id token
- 특정 리퀘스트에 권한을 주기 위해 사용되는 access token과는 달리 주 목적이 유저의 신원을 파악하기 위한 것임
- 유저의 이메일, 성, 이름, 나이 등이 저장 돼 있음
- OIDC에서는 id token을 항상 JWT 형식으로 발행함
- 서버에 요청을 보낼 때 같이 보내지지는 않음
- 유저 생성 과정에서 더 많은 정보를 가져오고 싶을 때
- 처음 부터 scope에서 해당 데이터에 대한 접근 권한을 정하고 리소스 서버의 access token을 붙인 리퀘스트를 보내서 해당 정보를 가지고 오면 됨
- access token과 OAuth는 형식이 따로 정해져 있지 않음
- 다른 정보가 필요하지 않을 시 access token은 사용하지 않아도 됨
- id token
다양한 OAuth/OpenID 플로우
- Implicit 플로우보다 Authorization Code 플로우가 더 권장되는 이유
- 안정성 때문
- Implicit 플로우를 사용하면 access token이 클라이언트 코드와 브라우저, 그리고 브라우저가 실행되고 있는 개인 컴퓨터에까지 노출되기 때문에 중간에 누군가가 가로챌 수 있는 가능성이 있음
- 프론트엔드에 저장된 정보는 백엔드 서버에 저장하는 것과는 달리 노출되기가 쉬움
- 따라서 Client Secret과 같이 민감한 정보를 저장하고 사용할 수 없음
- Client Secret을 사용하지 않고 access token을 발급하면 access token을 발급하는 대상이 정말 코드잇 서비스인지 확인하기 어려움
- 또한, 코드잇이 아닌 다른 사이트에 access token을 발급하는 것도 꽤 위험함
- 반면 Authorization Code는 프론트앤드는 Authorization code만 갖고 있고, Client Secret은 오직 백엔드 서버에만 저장돼있음
- 누군가 악의를 갖고 클라이언트 쪽에서 Authorization Code를 가로챈다고 해도 Authorization code의 유일한 기능은 인가 서버에 보내서 access나 id 토큰을 발행 받는 것이고 이때 Client ID와 Secret을 함께 보내야 하기 때문에 클라이언트 쪽에서 Authorization Code를 가로챈다고 해도 사용할 수 없음
아이디어와 구현을 좋아합니다!