OAuth 2.0

[에이콘] OAuth 2.0 마스터의 공부 내용을 정리한 것입니다.

authentication, authorization

• authentication(인증): User 자신을 증명하는 것. (ex.사이트 로그인 등)
• authorization(인가): 인증을 한 후 어떤 일을 할 수 있는 권한이 있는지 판단

delegated authority(권한 위임)

어떤 서비스나 앱에서 사용자의 리소스에 대신 접근할 수 있는 것

Grant

OAuth 2.0은 정보 교환을 위한 다양한 방법을 지원하고 그 방법에 따라 동작 흐름도 달라진다.

• authorization code grant
• 인가 코드 그랜트
• 서버 사이트 워크 플로우
• implicit grant
• 암시적 그랜트
• 클라이언트 사이드 워크플로우
• resource owner password credentials grant
• 리소스 소유자 비밀번호 자격증명 그랜트
• client credentials grant
• 클라이언트 자격증명 그랜트

trusted client, untrusted client

OAuth 2.0 클라이언트에는 두 가지 신뢰 레벨의 클라이언트가 있다.

• trusted client
• 클라이언트 자격증명과 토큰과 같은 리소스를 안전하게 저장할 수 있다.
• 백엔드 서버가 존재하는 전형적인 3계층 클라이언트-서버-데이터베이스 애플리케이션이 이에 해당한다.
• untrusted client
• 모든 정보가 브라우저에 저장돼야 하기 때문에 사용자는 저장한 정보에 완벽히 접근할 수 있고, 저장된 정보는 공개된 것으로 간주한다.
• html, JS로 구성된 브라우저 기반의 애플리케이션이 이에 해당

단어 정의

• User : 사용자. 고객
• client: 우리가 운영하는 사이트
• 서비스 제공자: user가 요청하는 리소스를 가진 서버

클라이언트 사이드 워크플로우

• 암시적 그랜트(implicit grant) 비신뢰 클라이언트이기 때문에 정보를 저장하고 전달하는 것을 신뢰할 수 없다. 특히 클라이언트 신분 증명이나 토큰을 저장할 수 없다. 이 때문에 흐름이 매우 단순하다.

서버와 클라이언트 사이에 인증이 완료되면 서버는 access token을 전달한다. access token은 사용자가 허가한 리소스만 접근할 수 있다. bearer 토큰이 가장 많이 사용된다. bearer 토큰은 물리적인 실제 키와 비슷하다. bearer 토큰이 있으면 누구든지 해당 사용자의 허가된 리소스에 접근할 수 있다.

언제 암시적 그랜트를 사용해야 하는가?

암시적 그랜트는 비신뢰 클라이언트를 위해 설계되었기 떄문에, 사용자의 데이터를 오랜 기간 저장할 필요가 없는 순수한 브라우저 기반의 애플리케이션에 적합하다.

• 브라우저에서 동작하는 웹어플리케이션
• 백엔드 서버 없이 동작하는 네이티브 iOS 애플리케이션

장점

• 구현이 매우 단순하다. 모든 동작이 브라우저에서 일어나므로 백엔드 서버나 데이터 저장이 필요하지 않다.

단점

• 보안성이 낮다. assecc key가 브라우저로 전달된다.
• 단기간 접근만 가능. 비신뢰 클라이언트이기 떄문에 오랜 기간 키를 저장할 수 없는데, 이는 신뢰 클라이언트보다 더 자주 인증을 갱신하고 토큰을 재발급 받아야함을 의미한다.

비신뢰 클라이언트를 개발한다면 서버의 권한을 읽기 전용 요청만 할 수 있도록 제한하는 것이 좋다. 사용자 데이터가 유출되어도 잠재적인 피해를 최소화 할 수 있다.

서버 사이트 워크플로우

• 인가 코드 그랜트(authorization code grant) 신뢰 클라이언트는 클라이언트 자격증명과 같은 정보를 안전하게 저장할 수 있다.

사용자가 서비스 제공자에게 client의 권한을 허락하면 서비스 제공자는 client에게 태그를 전달하고, 태그는 이후 키와 교환되어 client가 서비스 제공자의 리소스에 접근할 수 있게 된다.

키를 얻기 위해 사용하는 태그는 한 번만 사용이 가능하다.

OAuth 2.0에서 인가 코드(authorization code)가 태그에 해당한다. 태그는 보호된 리소스에 접근을 요청할 때 사용되는 액세스 토큰과 교환된다. 인가 코드와 토큰이 교환된 이후는 암기적 그랜트 유형와 동일한 워크플로우를 갖는다.

비신뢰 클라이언트와 중요한 차이점은 액세스 토큰이 브라우저에 절대 전달되지 않는다는 것이다. 그만큼 액세스 토큰이 유출되거나 탈취될 위험성이 줄어든다.

언제 인가 코드 그랜트를 사용해야 하는가?

신뢰 클라이언트를 위해 만들어졌기 때문에, 정보를 안전하게 저장하고 전송할 수 있는 클라이언트 애플리케이션에 적합하다. 일반적으로 클라이언트-서버 기반의 애플리케이션이다.

• 클라이언트는 HTML/JS 애플리케이션이고 서버는 SQL 데이터베이 서버와 연동된 백엔드로 구성된 클라이언트/서버 애플리케이션

장점

• 더 안전하다.
• 장기간 접근 가능

단점

• 더 복잡하다.안전하다는 장점을 이용하려면 좀 더 복잡한 키 교환을 가능하게 해주는 복잡한 인프라가 필요하다.

OAuth 2.0 워크플로우

1. 클라이언트 애플리케이션 등록
2. 액세스 토큰 얻기
3. 액세스 토큰을 이용해서 보호된 리소스 접근
4. 액세스 토큰 갱신 (신뢰 클라이언트의 경우에만 가능)

1. 클라이언트 애플리케이션 등록

애플리케이션 등록 후 사용하게 될 정보들

• client ID: 클라이언트 애플리케이션의 고유한 ID. 서비스 제공자에 등록된 클라이언트 애플리케이션중에서 반드시 유일해야 함
• client secret: 애플리케이션을 위한 비밀 키. 서비스 제공자에게 요청을 보낼때 애플리케이션의 신원을 알려주는 값. (implicit grant를 사용한다면 클라이언트 시크릿은 제공되지 않는다.)
• redirection endpoint: 서비스 제공자가 응답을 전달하기 위해 사용하는 엔드포인트.
• authorization endpoint: 클라이언트 애플리케이션이 인사 플로우를 시작할 때 사용하는 엔트포인트.
• token endpoint: 클라이언트 애플리케이션이 토큰 플로우를 시작할 때 사용하는 엔드포인트.

client credentials (자격증명)

기본적으로 클라이언트 ID와 클라이언트 시크릿.
클라이언트 애플리케이션을 식별하는데 사용된다.

2. 액세스 토큰 얻기

이 단계에서 인가 코드 그랜트 / 암시적 그랜트 으로 워크플로우가 결정된다.

Access Token

액세스 토큰은 범위(scope)와 접근 기간(duration of access) 속성을 갖는다.

• scope: 리소스 접근의 범위
• duration of access: 토큰의 만료 기간. 만료되기 전에 접근 권한을 종료/폐기해야 한다.
• refresh token: 액세스 토큰 발급시 같이 발급받으며, 액세스 토큰이 만료기간이 되었을때 새로운 액세스 토큰을 요청하여 세션을 갱신할때 사용.

3. 액세스 토큰을 이용해서 보호된 리소스 접근

액세스 토큰을 API 호출을 이용해 전달하여 리소스에 접근한다.

4. 액세스 토큰 갱신 (신뢰 클라이언트의 경우에만 가능)

보통 토큰의 만료시간은 몇 분에서 몇 시간 정도로 정해진다.

리프레시 토큰도 만료된다. 리프레시 토큰 갱신 방법은 인증 플로우를 다시 시작하는 방법밖에 없다.

redirection endpoint

서비스 제공자가 애플리케이션으로 컨트롤을 전달하고, 토큰이나 에러 메시지를 전달하기 위한 방법.
OAuth 2.0으로 인사 프로세스를 시작할 때 애플리케이션 이용자를 서비스 제공자의 인가 엔드 포인트로 로그인하도록 이끌고 해당 애플리이션을 인가(사용자 동의창)하도록 이끈다. 이 과정을 마치면 컨트롤은 다시 애플리케이션으로 넘어가야 한다. 이 과정이 리다이렉션 엔드포인트를 통해 이뤄진다. 애플리케이션 이용자가 로그인해서 애플리케이션을 인가하면 서비스 제공자는 이용자를 리다리엑션 엔드포인트로 리다이렉트시키고 동시에 세션 정보를 전달한다. 개발자는 리다이렉션 엔드포인트에서 전달된 정보를 파싱해야 한다.

인가 엔드포인트와 토큰 엔드포인트

서비스 제공자가 결정하고, 주로 서비스 제공자가 제공하는 문서에 명시한다. 제공자들중 일부는 OAuth 2.0을 이용하려면 자신이 제공하는 라이브러리나 SDK를 사용하도록 가이드한다. 그렇게 되면 서비스 제공자는 인가 엔드포인트와 토큰 엔드포인트를 노출하지 않아도 된다. 어떤식으로든 두 엔드포인트는 존재해야 하고 인증 플로우를 완료하기 위해 사용하게 된다.

출처 및 참조
OAuth 2.0 마스터
ㅇㅁ이상한모임