Home Oauth2
Post
Cancel

Oauth2

Posted Mar 5, 2023 Updated Jan 31, 2024
By haedal-uni
14 min read

OAuth

애플리케이션 인증을 위한 접근 관한 개방형 표준 프로토콜

  • 인증 : 사용자가 누구인지 확인하는 단계 ex) login
  • 권한 : 사용자가 해당 리소스에 접근할 권리가 있는지를 확인



Open Authorization의 약자로 인터넷 사용자들이 비밀번호를 제공하지 않고,

다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근권한을 부여할 수 있는 공통적인 수단으로

사용되는 접근 위임을 위한 개방형 표준이다.


OAuth가 사용되기 전에는 인증방식의 표준이 없었기 때문에 기존의 기본인증인 아이디와 비밀번호를 사용하였는데,

보안상 취약한 구조일 가능성이 매우 높았다.

OAuth는 이런 제각각 인증방식을 표준화한 인증방식이다.

OAuth를 이용하면 이 인증을 공유하는 애플리케이션끼리 별도의 인증이 필요없다.

따라서 여러 애플리케이션을 하나의 인증으로 통합 사용이 가능하다.




OAuth 2.0

OAuth 1.0과의 차이점

  • https를 통해 암호화를 해서 보완 강화
  • api서버에서 인증서버와 리소스 서버가 분리
  • scope 기능 추가 : token에 대한 접근 제한 범위 설정
  • token 탈취 문제 개선(Access Token + Refresh Token)
  • client 구현 복잡성 간소화 : Bearer Token + TLS



role

termdescription
Authentication신원 확인
Authorization권한 부여
Clientgoogle, facebook 등의 아이디로 로그인이 가능한 제 3의 서비스
Resource Ownergoogle, facebook 등의 아이디로 로그인하는 사용자
Resource Server회원의 정보를 저장하고 있는 서버(google, facebook 등)
Authorization Server로그인을 통해 인증 후 권한을 부여하는 서버(google, facebook 등)
Authentication Server실제로 로그인 서비스를 제공하는 서버(google, facebook 등)
Access Token실제 요청을 보낼 때 사용하는 토큰 (google, facebook 등에서 로그인 시 발급)
Refresh TokenAccess Token이 만료된 경우 재발급을 위해 사용하는 토큰 (google, facebook 등에서 로그인 시 발급)





OAuth2 Flow

사용자를 Resource Owner라고 하고 로그인하려고 하는 우리가 만든 서비스(로그인 하려는 서비스)를 Client,

사용자가 회원가입이 되어있는 서비스를 Resource Server라고 한다.

Resource Server와 Authorization Server로 나눌 수 있는데

데이터를 가지고 있는 서버와 인증과 관련된 처리를 전담하는 서버로 나눌 수 있다.

여기서는 설명을 위해 합쳐서 Resource Server라고 통일한다.


Resource Server에서 나의 id, password를 Client에 정보를 제공해줄 것이다.

이것은 id와 password를 공유하기 문에 보안상 좋지 않다.

oAuth를 사용하면 Resource Server에서 accessToken을 발급해주고

Client에서 accessToken으로 로그인을 할 수 있게 해준다.



Register

Resource Server를 이용하려면 Client가 사전에 승인을 받아야 한다.

이때, Redirect URI를 등록해야한다.

Redirect URI는 사용자가 OAuth 2.0 서비스에서 인증을 마치고 (ex. google login 페이지에서 로그인을 마쳤을 때)

사용자를 리디렉션시킬 위치이다.



OAuth 2.0 서비스는 인증이 성공한 사용자를 사전에 등록된 Redirect URI로만 리디렉션 시킨다.

승인되지 않은 URI로 리디렉션 될 경우, 추후 설명할 Authorization Code를 중간에 탈취당할 위험성이 있기 때문이다.

Redirect URI는 기본적으로 보안을 위해 https만 허용된다.

단, 루프백(localhost)은 예외적으로 http가 허용된다.

등록과정을 마치면, Client ID와 Client Secret를 얻을 수 있다.



image

Client ID는 공개되어도 상관없지만 Client Secret는 공개되면 안된다.

Authorized redirect URIs : 이 주소로 전달해주세요 (이 외의 주소로 오면 정보 안줌)




Resource Owner의 승인

사용하고자 하는 기능 B, C일때,

image

Resource Owner에 로그인이 되어있지 않으면 로그인을 하라고 요청한 후

로그인이 되면 Resource Server는 client의 id값과 같고 redirect_uri와 값이 같은지 확인한다.

값이 같다면 scope에 해당하는 권한을 client에게 부여할 것인지를 확인하는 메세지를 Resource Server가 Resource Owner에게 전송한다.

Resource Owner가 허용하게 되면 Resource Server는 정보를 수집해서 아래와 같이 서버에 저장한다.

image




Resource Server의 승인

Resource Server가 Client에게 accessToken을 발급하기 전에 임시 비밀번호를 발급한다.

image

authorization code = 3이라는 임시 비밀번호를 발급해서 Resource Owner에게 주면

Resource Owner는 모르게 해당 location 주소로 이동을 한다.

code=3번에 의해서 Client는 code=3이라는 값을 알게 된다.

image




Client는 해당 주소로 Resource Owner를 통하지 않고 Resource Server에 직접 접근한다.

image




Resource Server는 위 정보가 완전히 일치하면 Access Token을 발급한다.



Access Token 발급

인증을 했기 때문에 authorization code를 지운다.

그리고 accessToken을 발급한다. 그리고 Client에게 AccessToken 값을 응답해준다.

image





Referesh token

accessToken은 수명이 있다. 그 수명이 끝나면 api에 접속했을 때 db를 주지 않는다.

그러면 다시 발급을 하려면 위와 같이 해야되는데 그런 것을 하지 않고 referesh token을 발급할 수 있다.

image

Invalid Token Error이 뜨면 Access Token 수명이 다 된 것





OAuth 인증 방식 종류

인증 종류에는 4가지 방식이 있는데 이 중에서 나는 Authorization Code Grant Type 방식을 사용했다.

  • Authorization Code Grant Type
  • Implicit Grant Type
  • Resource Owner Password Credentials Grant Type
  • Client Credentials Grant Type



Authorization Code Grant Type

  • 권한 부여 코드 승인 타입

Resource Owner에게 사용 허락을 받았다는 증서인 권한 코드 (Authorization Code)를 가지고 AccessToken을 요청하는 방식

image

image

클라이언트가 파리미터로 클라이언트 ID, 리다이렉트 URI, 응답 타입을 code로 지정하여 권한 서버에 전달한다.

정상적으로 인증이 되면 권한 코드 부여 코드를 클라이언트에게 보낸다.

(응답 타입은 code, token 이 사용 가능하다. 응답 타입이 token 일 경우 암시적 승인 타입에 해당한다.)

성공적으로 권한 부여 코드를 받은 클라이언트는 권한 부여 코드를 사용하여 엑세스 토큰을 권한 서버에 추가로 요청한다.

이때 필요한 파라미터는 클라이언트 ID, 클라이언트 비밀번호, 리다이렉트 URI, 인증 타입이다.

마지막으로 받은 엑세스 토큰을 사용하여 리소스 서버에 사용자의 데이터를 보낸다.


보통 서버 사이드에서 인증을 처리하는 경우 이 방식을 많이 사용하고, (code에서도 이방식을 사용한다.)

Resource Owner에게 사용 허락을 받은 후 증서를 따로 받고,

이 증서와 함께 요청하는 방식이므로 다른 방식보다 조금 더 복잡하다.

대신 다른 방식보다 좀 더 신뢰성이 있는 방식이라 발급되는 액세스 토큰의 유효시간이 좀 더 길고,

다시 액세스 토큰을 발급받을 수 있는 Refresh Token을 함께 발급해 준다.




Implicit Grant Type

  • 암시적 승인 타입

Authorization Code Grant Type과 다르게 권한 코드 교환 단계 없이 엑세스 토큰을 즉시 반환받아 이를 인증에 이용하는 방식이다.

image

image

클라이언트가 파리미터러 클라이언트 ID, 리다이렉트 URI, 응답 타입을 code로 지정하여 권한 서버에 전달한다.

정상적으로 인증이 되면 권한 코드 부여 코드를 클라이언트에게 보낸다.

(응답 타입은 code, token 이 사용 가능하다. 응답 타입이 token 일 경우 암시적 승인 타입에 해당한다.)

응답 해준 Access Token 이 유효한지 검증 요청을 한다.

요청 받은 Access Token 정보에 대한 검증에 대한 응답값을 돌려준다.

유효한 Access Token 기반으로 Resource Server와 통신한다.




Resource Owner Password Credentials Grant Type

  • 리소스 소유자 암호 자격 증명 승인 타입

클라이언트가 암호를 사용해 엑세스 토큰에 대한 사용자의 자격 증명을 교환하는 방식

image

image

인증을 진행한다. 대부분 ID, Password를 통해서 자격 증명이 진행된다.

넘겨 받은 정보기반으로 권한 서버에 Access Token 정보를 요청한다.

Access Token 정보를 응답 받습니다. 이때 Refresh Token 정보도 넘겨 줄 수도 있다.

Access Token 기반으로 Resource Server와 통신한다.


리소스 소유자가 장치 운영 체제 또는 높은 권한을 가진 응용 프로그램과 같이 클라이언트와 신뢰 관계가 있는 경우에 적합하다.




Client Credentials Grant Type

  • 클라이언트 자격 증명 승인 타입

image

image

Access Token 정보를 요청한다.

Access Token 정보를 응답한다.
이때 Refresh Token 정보는 응답하지 않는 것을 권장한다.
별다른 인증 절차가 없기 때문에 Refresh Token 까지 넘기지 않는 것이라고 생각한다.

Access Token 기반으로 Resource Server와 통신한다.


클라이언트가 컨텍스트 외부에서 액세스 토큰을 얻어 특정 리로스에 접근을 요청할때 사용한다.





reference
OAuth 2.0. 생활코딩
OAuth란? & OAuth1 vs OAuth2
OAuth2 인증방식 종류들
OAuth 2.0 기반 인증 방식
OAuth 프로토콜의 이해와 활용 3 - OAuth 인증방식의 종류
[Spring] Spring Security 기본 개념 (JWT / OAuth2.0 / 동작 방식 / 구성 요소)
OAuth2 인증 방식 정리
OAuth 2.0 개념과 동작원리

Project, OAuth2
spring Security OAuth2
This post is licensed under CC BY 4.0 by the author.
Recently Updated
Contents