(항상 잘못된 정보가 포함되어 있을수 있습니다)
(잘못된 정보가 있다면 댓글로 피드백 부탁드리겠습니다)
OAuth란 인가를 받기 위한 표준 규칙 (프로토콜)이다.
내가 만든 서비스에서 사용자가 가지고있는 특정 서비스(예: 구글, 카카오, 네이버 등등)에 접근해서 특정 데이터를 만약 가져오고 싶다?
그러면 그 서비스에 인증을 해야할 것이다.
더 쉽게 예시를 들어보자
내 서비스에서 사용자의 편의성을 위해서 네이버라는 서비스에 네이버 메일을 정리해서 나열하는 기능이 있다고 해보자
내가 이런 기능을 만들기 위해서는 일단
이런 과정을 거칠것이다. 하지만 이런 과정은 아주 큰 문제가 있다
일단 사용자는 아이디와 비밀번호를 우리 서비스에 믿고 맡길수가 있을까? 우리가 메일 정보 뿐만아니라, 사용자의 네이버부동산정보, 보험정보 이런 다른 정보까지
우리 서비스가 볼수 있을꺼라는 불안함이 있을것이다.
우리서비스 또한 부담이 된다 이런 ID와 PW를 가지고 무언가를 하다가 사고가 발생하면 우리는 네이버라는 큰 기업을 상대로 얼마나 큰 책임을 물어야 할까?
네이버 입장에서도 마찬가지이다. 네이버도 보안을 위해 얼마나 많은 투자와 시행착오를 겪었는데 이걸 그냥 우리 서비스에서는 ID PW가 우리 서비스에 노출 된다면
무슨 말도 안되는 일일까?
처음으로 돌아와서 그럼 우리는 "사용자의 메일" 에 대한 권한만 필요한 상태이다.
이러한 권한을 받기위한 것이 이전 포스팅을 봤으면 알겠지만 "인가"다.
인가를 받기 위해서 선행되어야 할 것 이 있는데 그것이 바로 인증 이다.
우리가 사용자의 네이버 ID와 PW를 알 필요없이 보안적으로 안전하게 인가를 받을수 있는 방법은 무엇이 있을까?
OAuth는 바로 이러한 인증과 인가를 어떠한 표준 규칙으로 만들어둔것을 말한다.
인증은
사용자 <--> 인가를 내려주는 서비스 (네이버)
인가는
인가를 내려주는 서비스(네이버) <--> 우리 서비스
인증을 사용자와 해당 인가를 내려주는 서비스가 하도록 한다.
사용자는 네이버에 직접 로그인을 해서 인증 과정을 수행 하는 것이다.
우리서비스는 이과정에서 네이버에 로그인을 할수 있는 페이지를 열어준다던지 등등 이어줄수는 있지만
여기서 이 인증과정안에선 어떠한 참여도 하지 않는다.
그 뒤에 이 인증이 유요한 인증이라고 생각되면 인가를 내려주는 서비스인 네이버는
우리 서비스에게 메일에만 접근할수 있는 인가를 내려주게 되는것이다.
우리 서비스는 이 접근 권한을 이용해서 사용자의 메일에 접근할수 있게 된다.
여기서 용어 정리를 한번 하고 넘어가자
유저 = Resource Owner (사용자)
우리 서비스 = Client or Third Party Application (우리 앱)
인가를 내려주는 서비스쪽에서 인증을 검증하고 권한을 내려주는 주체 = Authorization Server (네이버 인증 서버)
인가를 내려주는 서비스쪽에서 리소스를 제공하는 주체 = Resource Server (네이버 메일 서버)
OAuth의 권한 부여 방식에는 4가지가 있다.
기본적인 권한 부여 플로우는 다음과 같다.
- 리소스 오너가 네이버 메일 정리 기능을 원한다.
- 우리 클라이언트는 로그인 페이지와 같은 것을 열어준다. (사용자한테 네이버 로그인 요구 및 네이버 로그인 페이지 제공)
- 리소스 오너와 Authorization 서버가 인증 과정을 거침 (사용자가 네이버에 로그인)
- 인증이 유효하다면 Authorization 서버는 엑세스토큰을 발급해 클라이언트에 제공 (인증이 유효하면 네이버가 우리앱에 액세스토큰으로 권한을 제공)
- 클라이언트는 이 엑세스 토큰을 가지고 Resource 서버에 접근 (우리 앱은 액세스토큰을 가지고 네이버 메일에 접근)
- 액세스 토큰 검증후 리소스를 제공 (네이버 메일은 엑세스 토큰을 검증후에 메일 정보를 제공)
- 클라이언트는 해당 리소스를 가공후 사용자에게 제공 (우리앱은 이 메일정보를 원하는 기능으로 구현후 제공)
- 리소스 오너가 인증을 수행 완료 후
- 클라이언트가 Authorization 서버로 OAuth 세팅할때 설정한 Client ID, Redirect URI, Response_type, Scope를 전달해서 인증 요구
- 인증 후에 Authorization 서버가 Authorization Code를 클라이언트에 발급하고
- 클라이언트는 이 Authorization Code와 필요한 정보들을 Authorization 서버에 전달
- Authorization 서버는 액세스 토큰 발급
- 리소스 오너가 인증을 수행 완료 후
- Authorization Code 방식과 같이 OAuth 세팅할때 설정한 값들을 전달
- Authorization Code 발급없이 바로 Authorization 서버에서 엑세스 토큰 발급
- 리소스 오너가 인증 수행 완료 후
- Authorization Code 서버로 엑세스 토큰 요청
- Authorization 서버는 엑세스 토큰 발급
- 리소스 오너가 인증 수행 완료 후 직접 Authorization 서버로 엑세스토큰 요청
- Authorization 서버는 엑세스 토큰 발급
OpenID Connect OIDC는 OAuth 보다 상위 계층에 있는 규칙 (프로토콜)이다.
OAuth는 인가를 위한 규칙이지. 인증을 위한 규칙은 아니다.
이러한 인증을 위한 규칙을 제공하는것이다 바로 OIDC 이다.
- OAuth에서 엑세스 토큰을 발급받는 과정 까지는 모두 같다.
- 하지만 여기서 엑세스 토큰과 함께 ID 토큰을 같이 발급 받는다.
- 이 ID토큰은 JWT를 통해 사용자 정보를 비롯한 정보가 암호화 되어 있다.
- 이를 통해서 회원가입을 하거나 로그인을 하는 등 인증과정을 밟을수 있게 해준다.