12/11[TIL]Authentication(3)

OAuth 2.0

인증을 위한 표준 프로토콜의 한 종류

보안된 리소스에 액세스 하기 위해 클라이언트에게 권한을 제공(Authorization)하는 프로세스를 단순화하는 프로토콜 중 한 방법

 

유저 입장에서 생각해보자면, 우리는 웹 상에서 굉장히 많은 서비스들을 이용하고 있고 각각의 서비스들을 이용하기 위해서는 회원가입 절차가 필요한 경우가 대부분인데 서비스별로 ID와 Password를 다 기억하는 것은 매우 귀찮은 일이다. 하지만 OAuth를 활용한다면 자주 사용하는 서비스들(예를 들어 google, github, facebook)의 ID와 Password만 기억해 놓고 해당 서비스들을 통해서 소셜 로그인을 할 수 있다.

뿐만 아니라 OAuth는 보안상의 이점도 있다. 검증되지 않은 App에서 OAuth를 사용하여 로그인한다면, 직접 유저의 민감한 정보가 App에 노출될 일이 없고 인증 권한에 대한 허가를 미리 유저에게 구해야 되기 때문에 더 안전하게 사용할 수 있다.

출처 : https://urclass.codestates.com/0fd81e3c-b097-43ad-9283-3aada1eca9db?playlist=426

 

OAuth에 사용되는 용어

• Resource Owner : 액세스 중인 리소스의 유저이다. 김 코딩의 구글 계정을 이용하여 App에 로그인을 할 경우, 이때 Resource owner은 김 코딩이 된다.

• Client : Resource owner를 대신하여 보호된 리소스에 액세스 하는 응용프로그램이다. 클라이언트는 서버, 데스크톱, 모바일 또는 기타 장치에서 호스팅 할 수 있다.

• Resource server : client의 요청을 수락하고 응답할 수 있는 서버이다.

• Authorization server : Resource server가 액세스 토큰을 발급받는 서버다. 즉 클라이언트 및 리소스 소유자를 성공적으로 인증한 후 액세스 토큰을 발급하는 서버를 말한다.

• Authorization grant : 클라이언트가 액세스 토큰을 얻을 때 사용하는 자격 증명의 유형으로 여기서 grant는 클라이언트 애플리케이션이 액세스 토큰을 얻는 방법을 뜻한다. grant 관련하여서는 밑에서 상세히 알아보자.

• Authorization code : access token을 발급받기 전에 필요한 code입니다. client ID로 이 code를 받아온 후, client secret과 code를 이용해 Access token을 받아옵니다. 일종의 허가증이다.

• Access token : 보호된 리소스에 액세스 하는 데 사용되는 credentials입니다. Authorization code와 client secret을 이용해 받아온 이 Access token으로 이제 resource server에 접근을 할 수 있다. 클라이언트에 발급된 권한을 나타내는 문자열 타입으로 이루어져 있다.

• Scope : scope는 토큰의 권한을 정의한다. 주어진 액세스 토큰을 사용하여 액세스 할 수 있는 리소스의 범위이다.

위의 용어에 비유를 하자면 아래와 같다.

Resource Owner : user 김 코딩

client : App

Resource Server : facebook

Authorization Server : facebook

Scope : image

 

 

Grant

grant는 클라이언트 애플리케이션이 액세스 토큰을 얻는 방법을 뜻한다.

각 grant 타입들은 웹앱, 네이티브 앱이든 웹브라우저를 출시할 수 능력이 없는 장치 등 서버대 서버 애플리케이션이던 특정 용도에 최적화가 된다.

 

Grant type 종류에는

Authorization Code Grant Type : 권한 부여 코드 승인 타입
클라이언트가 다른 사용자 대신 특정 리소스에 접근을 요청할 때 사용된다. 리스소 접근을 위한 사용자 명과 비밀번호, 권한 서버에 요청해서 받은 권한 코드를 함께 활용하여 리소스에 대한 엑세스 토큰을 받는 방식이다.

 

액세스 토큰을 받아오기 위해 먼저 Authorization code를 받아 액세스 토큰과 교환하는 방법으로 Authorization code 절차를 거치는 이유는 보안성 강화에 목적이 있다. client에서 client – secret을 공유하고 액세스 토큰을 가지고 오는 것은 탈취될 위험이 있기 때문에 client에서는 Authorization code만 받아오고 Server에서 Access Token요청을 진행한다.

 

 

출처 : https://urclass.codestates.com/0fd81e3c-b097-43ad-9283-3aada1eca9db?playlist=426

출처 : https://urclass.codestates.com/0fd81e3c-b097-43ad-9283-3aada1eca9db?playlist=426

 

 

 

 

 

Implicit Grant Type : 암시적 승인
권한 부여 코드 승인 타입과 다르게 권한 코드 교환 단계 없이 액세스 토큰을 즉시 반환받아 이를 인증에 이용하는 방식입니다.

 

Resource Owner Password Credentials Grant Type : 리소스 소유자 암호 자격 증명 타입
클라이언트가 암호를 사용하여 엑세스 토큰에 대한 사용자의 자격 증명을 교환하는 때입니다.

 

Client Credentials Grant Type : 클라이언트 자격 증명 타입
클라이언트가 콘텍스트 외부에서 액세스 토큰을 얻어 특정 리소스에 접근을 요청할 때 사용하는 방식입니다.

 

Refresh Token Grant Type

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

일정 기간 유효 시간이 지나서 만료된 액세스 토큰을 편리하게 다시 받아오기 위해 사용하는 방법으로 이 방법이 없다면 만료될 때마다 사용자에게 인증 권한을 요청하는 것을 불편하기에 사용한다.

refresh가 되는 기준이 서버 서비스마다 다르기 때문에 그 서버의 문서를 확인하는 것이 필요하다.

Access Token보다 Refresh Token의 유효 시간이 대체로 조금 더 길게 설정하기 때문에 가능한 방법이다.

 

출처 : https://urclass.codestates.com/0fd81e3c-b097-43ad-9283-3aada1eca9db?playlist=426