OAuth

OAuth란

OAuth는 다양한 플랫폼 환경에서 권한 부여를 위한 산업 표준 프로토콜입니다. 간단하게 인증(Authentication)과 권한(Authorization)을 획득하는 것으로 볼 수 있습니다. 여기서 인증은 시스템 접근을 확인하는 것이고 권한은 행위의 권리를 검증하는 것입니다.

OAuth 1.0

third party Application에 아이디와 비밀번호를 제공하고 싶지 않은 요구로 인해 OAuth가 탄생했습니다. 개인 정보를 여러 곳에 입력하면서 피싱에 둔감해지고 무엇보다 Application이 안전하다는 보장이 없기 때문에 보안에 취약했습니다.

OAuth 2.0

OAuth 1.0과 달라진 점

• 기능의 단순화, 기능과 규모의 확장성 등을 지원하기 위해 만들어졌습니다.
• https가 필수이기 때문에 간단해졌습니다.
• 암호화는 https에 맡겼습니다.
• OAuth 1.0은 인증방식이 한 가지였지만 OAuth 2.0은 다양한 인증방식을 지원합니다.
• Api서버에서 인증 서버를 분리할 수 있도록 했습니다.

OAuth 2.0의 인증 프로세스

OAuth 2.0의 인증 종류

Authrozation Code Grant
서버사이드 코드로 인증하는 방식으로 권한 서버가 클라이언트와 리소스 서버간의 중재 역할을 합니다. Access Token을 바로 클라이언트로 전달하지 않아 잠재적 유출을 방지합니다. 로그인 시에 페이지 URL에 reponse_type=code라고 넘깁니다.

Implicit Grnat
OAuth 2.0에서 가장 많이 사용되는 방식으로, Token과 Scope에 대한 스펙 등은 다르지만 OAuth 1.0과 가장 비슷한 인증방식입니다. Public Client인 브라우저 기반의 어플리케이션이나 모바일 어플리케이션에서 이 방식을 사용하면 됩니다. 권한코드 없이 바로 발급되서 보안에 취약하기 때문에 주로 Read only인 서비스에 사용됩니다. 로그인시에 페이지 URL에 response_type=token이라고 넘깁니다.

Password Credentials Grant
Client에 아이디/패스워드를 저장해 놓고 아이디/패스워드로 직접 Access Token을 받아오는 방식입니다. Client를 믿을 수 없을 때에는 사용하기 위험하기 때문에 API 서비스의 공식 어플리케이션이냐 믿을 수 있는 Client에 한해서만 사용하는 것을 추천합니다. 로그인 시에 API에 POST로 grant_type=password라고 넘깁니다.

Client Credentials Grnat
어플리케이션이 Confidential Client일 때 id와 secret을 가지고 인증하는 방식입니다. 로그인 시에 API에 POST로 grant_type=client_credentials라고 넘깁니다.

Token

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

Refresh Token
한 번 발급받은 Access Token은 사용할 수 있는 시간이 제한되어 있습니다. 사용하고 있던 Access Token이 유효기간 종료 등으로 만료되면, 새로운 Access Token을 얻어야 하는데, 그 때 Refresh Token이 사용됩니다. 권한 서버가 Access Token을 발급해주는 시점에 Refresh Token도 함께 발급하여 클라이언트에게 알려주기 때문에, 전용 발급 절차 없이 Refresh Token을 미리 가지고 있을 수 있습니다. Token의 형태는 Access Token과 동일하게 문자열 형태입니다. 단 권한 서버에서만 활용되며 리소스 서버에는 전송되지 않습니다.

토큰의 갱신 과정
클라이언트가 권한 증서를 가지고 권한 서버에 Access Token을 요청하면, 권한 서버는 Access Token과 Refresh Token을 함께 클라이언트에 알려줍니다. 그 후, 클라이언트는 Access Token을 사용하여 리소스 서버에 각종 필요한 리소스들을 요청하는 과정을 반복합니다. 그러다가 일정한 시간이 흐른 후, Access Token이 만료되면 리소스 서버는 이후 요청들에 대해 정상 결과 대신 오류를 응답하게 됩니다. 오류 등으로 Access Token이 만료됨을 알아챈 클라이언트는, 전에 받아 두었던 Refresh Token을 권한 서버에 보내어 새로운 Access Token을 요청합니다. 갱신 요청을 받은 권한 서버는 Refresh Token의 유효성을 검증한 후, 문제가 없다면 새로운 Access Token을 발급해줍니다. 이 과정에서 옵션에 따라 Refresh Token도 새롭게 발급될 수 있습니다.