Spring Security - OAuth2 && JWT (JSON Web Token) - 1

spring security 를 통해서 OAuth2 구현을 해 볼 예정이며, 먼저 이번 글에서는 OAuth2 개념과 JWT 개념에 대해서 정리해보려고 한다.


 OAuth 2 란?



OAuth 2.0 권한 부여 프레임워크를 사용하면 타사 애플리케이션의 자원 소유자와 HTTP 서비스 간의 승인 상호 작용을 조정해 자원 소유자를 대신해 HTTP 서비스에 대한 제한된 접근 권한을 얻거나 타사 애플리케이션이 자체적으로 접근 권한을 얻는다. 해당 사양은 RFC 5849, The OAuth 1.0 Protocol 에 설명된 더 이상 사용하지 않는 OAuth 1.0 프로토콜을 대체한다.

    The OAuth 2.0 authorization framework enables a third-party
   application to obtain limited access to an HTTP service, either on
   behalf of a resource owner by orchestrating an approval interaction
   between the resource owner and the HTTP service, or by allowing the
   third-party application to obtain access on its own behalf.  This
   specification replaces and obsoletes the OAuth 1.0 protocol described
   in RFC 5849.



OAuth 2 를 활용하는 방법을 제대로 이해하려면 특정 역할과 역할 간의 관계를 이해해야 한다. 그렇다면, 각 권한 부여 프로세스에 참여하는 역할을 살펴보자.


OAuth defines four roles:

   resource owner
      An entity capable of granting access to a protected resource.
      When the resource owner is a person, it is referred to as an
      end-user.

   resource server
      The server hosting the protected resources, capable of accepting
      and responding to protected resource requests using access tokens.

   client
      An application making protected resource requests on behalf of the
      resource owner and with its authorization.  The term "client" does
      not imply any particular implementation characteristics (e.g.,
      whether the application executes on a server, a desktop, or other
      devices).

   authorization server
      The server issuing access tokens to the client after successfully
      authenticating the resource owner and obtaining authorization.

  • 자원 소유자 : 자원 서버에 위치한 보호 자원에 대한 접근 권한을 부여할 수 있는 객체. 자원 소유자가 사람일 때, 엔드 유저로 추론된다.
  • 자원 서버 : 보호 자원을 호스팅하는 서버이며, OAuth 2 액세스 토큰을 사용해 보호된 자원 요청을 해석하고 응답한다.
  • 클아이언트 : 자원 소유자를 대신해 권한이 부여된 자원을 요청하는 어플리케이션. "client" 라는 용어는 어떤 특정한 성질의 구현을 암시하는 것이 아니다. ( 예를 들어, 어플리케이션이 특정 서버나 데스크탑 혹은 다른 기기에서 실행되는지)
  • 권한 부여 서버 : 자원 소유자를 성공적으로 인증하고 권한을 얻은 후 access token 을 클라이언트에게 발행하는 서버.

access_token 종류

  • 먼저 access_token 은 클라이언트가 API에 접근하는 데 사용할 수 있는 자격 증명을 나타낸다. 일반적으로 액세스 토큰은 제한된 수명을 가지며, 클라이언트가 각 요청의 HTTP 헤더에 액세스 토큰을 포함할 때 보호된 자원에 접근할 수 있도록 한다.
  • refresh_token 은 수명이 길며 액세스 토큰이 만료되면 서버에 자격 증명을 다시 보낼 필요 없이 새로운 액세스 토큰을 얻는 데 사용된다.

권한 부여 방식

클라이언트가 부여된 사용 권한을 포함하는 access_token 을 얻는 데 사용할 수 있는 방법이다.

1. Authorization Code Grant - redirection 기반 흐름으로, 웹 브라우저가 승인 서버에서 권한 부여 코드를 받아 이를 클라이언트에게 전달한다. 그러면 클라이언트는 권한 부여 서버와 상호 작용하고 access_token 또는 선택적으로 id_token 과 refresh_token 에 대한 권한 부여 코드를 교환한다. 마지막으로 클라이언트는 해당 access_token 을 사용해 사용자 대신 보호된 자원을 호출할 수 있게 된다.
OAuth 인증 코드 흐름


2. Implicit Grant - Authorization Code Grant 와 유사하지만 클라이언트 어플리케이션은 authorization_code 를 요구하지 않고 직접 access_token 을 수신한다. 일반적으로 웹 브라우저에서 실행되는 자바스크립트 어플리케이션이며 서버에서 실행되는 클라이언트 어플리케이션보다 신뢰도가 낮은 클라이언트 어플리케이션이 client_secret 으로 신뢰할 수 업기 때문에 발생한다. 또한 제한된 신뢰로 인해 어플리케이션에 refresh_token 을 보내지 않는다.
암시적 로그인 흐름을 보여 주는 다이어그램

3. Resource Owner Password Credentials Grant - access_token 또는 선택적으로 refresh_token 을 얻기 위해 권한 부여 방법으로 직접 사용할 수 있다. 사용자와 클라이언트 간에 높은 신뢰도가 있고 다른 권한 부여 플로우를 사용할 수 없는 경우에 사용한다. 또한 클라이언트가 장시간 사용되는 access_token 또는 refresh_token 으로 자격 증명을 교환해 사용자 자격증명을 저장할 필요가 없다.
리소스 소유자 암호 자격 증명 흐름을 보여 주는 다이어그램

4. Client Credentials Grant - 비대화형 클라이언트 (CLI) , 데몬 또는 실행 중인 다른 서비스용이다. 클라이언트는 권한 부여를 위해 클라이언트 제공 자격 증명 (클라이언트 ID 및 패스워드) 을 사용해 권한 서버에 access_token 을 직접 요청할 수 있다.
클라이언트 자격 증명 흐름을 보여 주는 다이어그램


JSON Web Token 이란 ?

JSON 객체의 형태로 당사자 간에 정보를 안전하게 전송하기 위한 소형의 자체 포함 형식으로 정의된다. 이때 정보는 디지털 서명되었기 때문에 검증할 수 있으며 신뢰할 수 있다. JWT 는 해시 기반 메세지 인증 코드(HMAC) 알고리즘을 사용하는 비밀키 또는 RSA 암호화 알고리즘을 사용하는 공개 및 개인키 쌍을 사용해 서명할 수 있다.

    JSON Web Token (JWT) is a compact, URL-safe means of representing
   claims to be transferred between two parties.  The claims in a JWT
   are encoded as a JSON object that is used as the payload of a JSON
   Web Signature (JWS) structure or as the plaintext of a JSON Web
   Encryption (JWE) structure, enabling the claims to be digitally
   signed or integrity protected with a Message Authentication Code
   (MAC) and/or encrypted.
   https://tools.ietf.org/html/rfc7519

양측 간에 전송될 클레임을 표현하기 위한 소형의 URL 안전 수단이다. JWT claim 은 JSON 객체로 인코딩되어 JSON Web Signature (JWS) 구조의 payload 로 사용되거나, JSON Web Encryption (JWE) 구조의 일반 텍스트로 사용되어 claim 을 디지털 서명하거나, Message Authentication Code (MAC) 및 암호화를 통해 무결성 보호할 수 있도록 한다.

JWT 토큰을 소유한 클라이언트의 신원과 특성 (claim) 과 관련된 정보를 전달하는 데 사용하며, JWT 는 컨테이너이며 클라이언트 변조를 피하기 위해 서버가 서명한다. JWT 토큰은 권한 부여 프로세스 중에 생성되며 처리 전에 권한 부여 서버가 검증한다. 또한 자원 서버는 클라이언트가 "ID 카드" 를 나타내는 토큰을 제공할 수 있게 하며, 자원 서버가 상태를 저장하지 않고(stateless), 보안 방식으로 토큰의 유효성 및 무결성을 검증할 수 있게 한다.

토큰 구조

Header, Payload, Signature 구조를 가진다.


간단하게 OAuth2 와 JWT 에 대해서 정리해 보았다. 다음 글에서 Spring security 를 통해서 구현을 해보겠당

댓글

이 블로그의 인기 게시물

About JVM Warm up

About idempotent

About Kafka Basic

About ZGC

sneak peek jitpack

Spring Boot Actuator readiness, liveness probes on k8s

About Websocket minimize data size and data transfer cost on cloud

About G1 GC

대학생 코딩 과제 대행 java, python, oracle 네 번째