[Back-end] OAuth

Geun·2022년 3월 30일

Back-end

목록 보기

40/74

OAuth

외부 서비스에서도 인증을 가능하게 하고, 그 서비스의 API를 이용하게 해주는 위와 같은 것을 OAuth라고 한다.
OAuth는 간단하게 인증(Authentication)과 권한(Authorization)을 획득하는 것으로 볼 수 있다.

인증은 시스템 접근을 확인하는 것이다.(로그인) -> 인증만 하는 것은 openID이다.
권한은 행위의 권리를 검증하는 것이다.

배경

third party application에 아이디와 비밀번호 정보를 제공하지 않는 것이 첫번째이다.
application이 안전하다는 보장이 없기 때문에 보안에 취약했다.

예전에는 인증과 권한을 부여하는 요구를 만족시킬 인증방식이 없었고, Twitter의 주도로 OAuth 1.0이 탄생했다.

비밀번호 인증방식의 문제는 다음과 같다.

신뢰: 사용자가 애플리케이션에 ID/PW를 제공하기 꺼려한다.
피싱에 둔감해짐: 각 종 애플리케이션들에 ID/PW 를 계속 제공하는 경우
접근범위가 늘어남에 따른 위험 부담: ID/PW를 모두 알고 있는 애플리케이션은 모든 권한을 가진다.
신뢰성의 제한: PW 를 변경한다면 애플리케이션은 동작을 하지 못하게 된다.
폐기문제: 권한을 폐기할 수 있는 유일한 방법이 PW를 변경하는 것

OAuth 2.0

OAuth 1.0 에서는 구현이 복잡하고 웹이 아닌 어플리케이션에서의 지원이 부족하였다.
HMAC를 통해 암호화를 하는 번거로운 과정을 겪었다. 또 인증토큰(access token)이 만료되지 않는다.

OAuth 2.0는

기능이 단순화 되었다. 기능과 규모의 확장성 등을 지원하기 위해 만들어졌다.
1.0a는 만들어진 다음 표준이 되었지만 2.0은 처음부터 표준 프로세스로 만들어졌다.
암호화가 필요 없다. HTTPS를 사용하고 HMAC을 사용하지 않는다.
1.0a는 인증방식이 한가지 였지만 2.0은 다양한 인증방식을 지원한다.
api 서버에서 인증서버를 분리할 수 있도록 해 놓았다.
Siganature 단순화 정렬과 URL 인코딩이 필요 없다.
OAuth 1.0에서 Access Token을 받으면 Access Token을 계속 사용할 수 있었다. 트위터의 경우에는 Access Token을 만료시키지 않는다. OAuth 2.0에서는 보안 강화를 위해 Access Token의 Life-time을 지정할 수 있도록 했다.

OAuth 2.0 구성

Resource owner: 사용자.
Client: Resource Server 에서 제공하는 자원을 사용하는 애플리케이션 (페이스북의 뉴스를 모아서 보여주는 앱)
Resource server(API server): 자원을 호스팅하는 서버 (페이스북 사진 비디오 등)
Authorization Server: 사용자의 동의를 받아서 권한을 부여하는 서버, 일반적으로 Resource Server 와 같은 URL 하위에 있는 경우가 많다.

OAuth 인증 프로세스

발급받은 Access Token은 서비스에서 자체적으로 저장, 관리해야 한다.

OAuth 인증 종류

OAuth 2.0의 인증종류는 4가지이다.

Authorization Code Grant

서버사이드 코드로 인증하는 방식이다.
권한 서버가 클라이언트와 리소스 서버간의 중재 역할을 한다.
Access Token을 바로 클라이언트로 전달하지 않아 잠재적 유출을 방지한다.

로그인 시 페이지 URL에 response_type=code 라고 넘긴다.

Implict Grant

token과 scope에 대한 스펙 등은 다르지만 OAuth 1.0a과 가장 비슷한 인증방식이다.
Public Client인 브라우저 기반의 어플리케이션(Javascript application)이나 모바일 어플리케이션에서 이 방식을 사용하면 된다.
OAuth 2.0에서 가장 많이 사용되는 방식이다.
권한코드 없이 바로 발급되서 보안에 취약

주로 Read only인 서비스에 사용한다.
로그인시에 페이지 URL에 response_type=token 라고 넘긴다.

Resource Owner Password Credentials Grant

Client에 아이디/패스워드를 저장해 놓고 아이디/패스워드로 직접 access token을 받아오는 방식이다.
Client 를 믿을 수 없을 때에는 사용하기에 위험하기 때문에 API 서비스의 공식 어플리케이션이나 믿을 수 있는 Client에 한해서만 사용하는 것을 추천한다.

로그인시에 API에 POST로 grant_type=password 라고 넘긴다.

Client Credential Grant

어플리케이션이 Confidential Client일 때 id와 secret을 가지고 인증하는 방식이다.

로그인시에 API에 POST로 grant_type=client_credentials 라고 넘긴다.

Token

Access Token

위에 적은 4가지 권한 요청방식을 모두 정상적으로 마치면, 클라이언트에게 Access Token이 발급된다.
이 Token은 보호된 리소스에 접근할 때 권한 확인용으로 사용된다.
문자열 형태이며 클라이언트에 발급된 권한을 대변하게 된다.
계정 아이디, 비밀번호 등 계정 인증에 필요한 형태들을 이 토큰 하나로 표현함으로써 리소스 서버는 여러가지 인증방식에 각각 대응하지 않아도 권한을 확인할 수 있게 된다.

Refresh Token

한 번 발급받은 Access Token은 사용할 수 있는 시간이 제한되어 있다.
가지고 있던 Access Token의 기간이 만료되면 새로운 액세스 토큰을 얻을 때 Refresh Token이 활용된다.
권한 서버가 Access Token을 발급해주는 시점에 Refresh Token도 함께 발급해 클라이언트에게 알려주기 때문에 전용 발급절차가 없더라도 Refresh Token을 미리 가지고 있을 수 있다!

Token의 형태는 Access Token과 동일하게 문자열 형태이다.
다만 권한 서버에서만 활용되고 리소스 서버에는 전송되지 않는다.

토큰의 갱신과정

클라이언트가 권한 증서를 가지고 권한 서버에 Access Token을 요청하면 권한서버는 Access Token과 Refresh Token을 함께 클라이언트에 알려준다.
그 후 클라이언트는 Access Token을 사용해 리소스 서버에 필요한 여러개의 리소스들을 요청하는 과정을 반복한다. 그러다 일정 시간이 흐른 후 액세스 토큰이 만료되면. 리소스 서버는 이후 요청들에 대해 정상 결과 대신 오류라고 알려주게 된다.
오류 등으로 액세스 토큰이 만료되었음을 알게된 클라이언트는 전에 받아둔 Refresh Token을 권한 서버에 보내 새로운 Access Token을 요청한다.
갱신 요청을 받은 권한 서버는 Refresh Token의 유효성을 검증하고 문제가 없다면 새로운 Access Token을 발급해준다.
이 과정에서 옵션으로 Refresh Token도 새롭게 발급될 수 있다.