OAuth : Open Authorization (+Authentication)
OAuth 는 “인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹 사이트 상의 자신들의 정보에 대해
웹사이트나 어플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는, 접근 위임을 위한
개방형 표준 프로토콜이다.” (위키백과)
무슨 말인데 이게
예를 들어 “juju” 라는 웹사이트가 있다고 하자.
juju 는 사용자 인증을 위해 Google 이나 Kakao 등의 소셜 로그인 방식을 사용한다.
이렇게 로그인하게 되면 juju 는 외부 서비스 (Google, Kakao) 의 특정 자원을 접근 및 사용할 수 있는 권한을
인가 받게 된다. 이때 사용되는 프로토콜이 바로 OAuth !
접근 권한을 위임 받을 수 있는 표준 프로토콜 !
방금 인가 라는 말을 썼는데, 인증(Authentication)과 인가(Authorization)는 다르다.
인증은 “이 사용자가 검증된 사용자인지” 확인하는 것이고, 인가는 “이 사용자가 해당 권한이 있는지” 확인하는 것이다.
예를 들어 소셜로그인에서 Google 로그인 자체는 인증의 과정이고,
Google 로그인 후 캘린더 정보를 가져올 수 있는 사용자인지 확인하는 것은 인가의 과정이라고 볼 수 있다.
OAuth 왜 쓰나
쉽게 말해서 juju 라는 서비스 자체에서 아이디 비밀번호를 이용해서 로그인을 하도록 만들지 않고
Google 아이디와 비밀번호를 이용해서 구글에 로그인하고, 그 정보를 가지고 회원 인증을 진행하는 것이다.
근데 juju 를 이용하는 사용자가 구글 회원이라는 건 어떻게 인증할까?
🙋♂️ : 사용자한테 직접 아이디, 비밀번호를 받아서 로그인을 해보면 됩니다.
말도 안 되는 방법이다 .. 그래서 OAuth 가 생겼다 !
다른 서비스의 회원 정보를 쉽고, 안전하게 사용하는 방법이 바로 OAuth 이다.
OAuth 는 단순히 사용자 인증을 하는 것 뿐 아니라 특정 권한을 주는 데에 목적이 있다.
Authentication 도 있지만, 주 목적은 Authorization !
OAuth 1.0
구성
- user
- consumer
- service provider
- consumer secret
- request token
- access token
먼저 OAuth 1.0 에 대해서 알아보자.
OAuth 1.0 에는 사용자(user), 소비자(consumer), 서비스 제공자(service provider)가 있다.
이 세 가지 요소가 상호작용하는 형태라고 생각하면 된다.
진행 과정은 아래와 같다.
- consumer 가 service provider 에게 Request Token 요청.
- service provider 가 consumer 에게 Request Token 발급.
- consumer 가 user 를 service provider 로 redirect.
- user 가 service provider ID/비밀번호 입력 (인증 수행)
- service provider 가 user 를 consumer 로 redirect.
- consumer 가 service provider 에게 Access Token 요청.
- service provider 가 consumer 에게 Access Token 발급.
- 발급된 Access token 을 이용하여 consumer 가 user 정보에 접근.
여기서 Request Token 은 service provider 가 권한 부여 요청을 확인했다고 consumer 에게 주는
일종의 임시 티켓 같은 것이다.
인증이 수행되고 user 가 consumer 에게 권한을 부여했음이 확인(Request Token 을 통해)되면,
service provider 가 Access Token (보호 자원 접근 티켓) 을 consumer 에게 발급하는 형태 !
문제점
- 웹이 아닌 어플리케이션에서 지원 부족
- HMAC 을 통해 암호화 하는 과정이 번거로움
- access token 이 만료되지 않음
→ 그래서 2.0 이 등장 🙌
2.0이 나오기 전, Access Token 이 노출될 수 있는 위험이 있기 때문에 이를 보완한 1.0a 방식이 나왔었다.
Access Token 을 Redirect 를 이용해 전송하지 않고 중간에 확인 코드를 이용해
백채널에서 Access Token 을 Consumer 로 바로 전송하도록 변경 !
하지만 아직도 위 문제점은 존재 ..
OAuth 2.0
OAuth 1.0 과 비교하여 2.0에서 달라진 점은 아래와 같다.
- HTTPS 가 필수 ! 암호화는 HTTPS 에 위임.
- API 서버에서 인증서버를 분리
- 다양한 인증 방식 지원
- 만들어질 때부터 표준 프로세스로 만들어짐
OAuth 2.0 의 주체로는 Resource Owner, Client, Resource Server, Authorization Server 가 있다.
Resource Owner: Google 이나 Kakao 와 같은 플랫폼에 정보를 가지고 있는 사용자를 의미한다.Client: Resource Server 의 자원을 이용하고자 하는 서비스. 우리가 만든 서비스가 이에 해당한다.Authorization Server: Resource Owner 에 대해 인증하고, Client 에게 Access Token 을 발급해주는 서버Resource Server: Google, Kakao 와 같이 정보를 가지고 있는 서버
그럼 2.0 에서는 어떻게 인증 과정을 거치는지 살펴보자.
인증과정을 순서대로 살펴보자.
1~5 단계는 사용자가 Google 이나 Kakao 와 같은 서비스에 로그인을 시도하면, Authorization Code 를 발급받는 과정.
7~8 단계는 해당 Authorization Code 를 이용해서 Client 가 Access Token 을 발급받는 과정.
10~11 단계는 발급받은 Access Token 을 이용해서 Client 가 회원정보를 받아오는 과정.
위 과정은 OAuth 2.0 의 인증 종류 중 흔하게 볼 수 있는 Authorization Code Grant 방식이다.
다른 방식들도 있지만, 일단 이 방식을 기준으로 이해해보자.
Access Token
먼저 OAuth 의 핵심인 Access Token 은 일종의 위임장 같은 것이다.
Access Token 은 일종의 문자열이고, 이 토큰을 이용해 Google 과 같은 서비스는 인증된 사용자라는 것을 판단한다.
어쨌든 이 Access Token 을 Client 가 가지고 있다면,
사용자의 정보를 Client 가 확인하도록 사용자가 동의했다는 일종의 증표인 셈이다.
위 과정의 11~12 번에서 Client 는 Resource Server 에서 사용자의 정보를 가져와서 볼 수 있는 것이다.
Authorization Code
사용자가 Google 에 로그인을 해서 Access Token 을 발급받았다고 치자.
그럼 Client 는 이 Access Token 을 어떻게 받을 수 있을까?
사용자가 받은 Access Token 을 다시 Client 쪽으로 전송하도록 구현할 수도 있지만,
그렇다면 XSS 나 피싱 사이트 등에서 Access Token 을 탈취할 수 있는 보안적 위험이 존재한다.
그래서 Access Token 을 직접 사용자단까지 전달하지 않고 Client 와 OAuth 서버 간에 전달할 수 있도록
인증 코드를 교환하는 단계를 하나 더 거치는 것이 위에서 잠깐 얘기한 Authorization Code Grant 방식이다.
이 과정은 위 예시 사진에서 1~6에 해당하는 단계이다.
쉽게 설명하자면 사용자가 웹브라우저를 이용해 Google 로그인을 진행하면
바로 Access Token 을 응답으로 주는 것이 아니라 Authorization Code 를 발급한다.
그리고 이 코드를 HTTP Redirect 를 이용해서 전송한다.
Client 는 해당 Authorization Code 를 이용해서 OAuth 서버로 Access Token 을 요청하고,
발급받은 Access Token 으로 사용자 정보를 조회하는 구조 !
즉 Authorization Code 가 발급된 이후부터는 사용자 단에 Access Token 이 노출되지 않는다.
이렇게 하면 토큰이 탈취될 수 있는 위험이 사라진다.
🙋♂️ : Authorization Code 가 탈취되면 똑같지 않나요 ?
OAuth 서비스를 이용하기 위해 먼저 OAuth 서버에 정보를 등록해야 하는데,
그때 Authorization Code 를 받을 Redirect_uri 를 약속하고,
OAuth 서버에서 알려주는 client_id 와 client_secret 을 이용해 Client 를 식별한다.
예를 들어 해커가 다른 Redirect_uri 로 Authorization Code 를 받으려고 한다면,
Google 에서는 등록된 Redirect_uri 와 다르기 때문에 보내주지 않는다.
또 Authorization Code 를 탈취해도 client_id 와 client_secret 을 모르기 때문에
Access Token 을 받을 수 없다 !
인증 종류
OAuth 2.0 에서 달라진 점으로 다양한 인증 방식을 지원한다고 했는데, 총 4가지의 인증 방식이 있다.
- Authorization Code Grant
위의 예시로 보인바와 같다. - Implicit Grant
- Password Credentials Grant
- Client Credentials Grant
이건 다음에 알아보자