[Spring] Jwt 와 OAuth2.0 간단하게 알아보기

 

먼저 실제 코드를 적용해보기 전 JWT 와 OAuth2 가 무엇인지 이론적으로 간단히 알아봅시다!

 

Jwt (Json Web Token) 이 무엇일까?

 

 

클라이언트와 서버가 통신할때 유저를 인증하고 식별하는 토큰이 바로 JWT 입니다. JSON 포맷을 이용해 사용자에 대한 속성을 저장하고 토큰 자체를 정보로 사용하는 Self - Contained 방식으로 정보를 안전하게 전달할 수 있습니다. 주로 회원 인증이나 정보 전달에 많이 사용됩니다.

 

JWT 구조

 

JWT는 Json 데이터를 표준 규약에 따라 암호화된 String 형태로 저장되어 있고 헤더(Header), 페이로드(Payload), 서명(signature) 3가지 영역으로 구성되어 있습니다.

 

 

 

이제 각각의 영역이 어떤 역할을 하는지 알아봅시다.

 

---

Header (헤더)

 

Header 는 두가지 정보를 가지고 있습니다. 

 

{
	"typ" : "JWT",
    "alg" : "HS512"
}

 

typ : 토큰의 타입을 지정합니다.

alg : 해싱 알고리즘을 지정합니다. JWT 에서는 보통 HS512 라는 알고리즘을 사용합니다.

 

---

Payload (페이로드)

 

{
    "iss": "velopert.com",
    "exp": "1485270000000",
    "https://velopert.com/jwt_claims/is_admin": true,
    "userId": "11028373727102",
    "username": "velopert"
}

 

payload는 토큰에 담을 정보가 들어있습니다. payload 에 담는 정보의 조각을 클레임(claim) 이라 부르고 key - value 로 구성된 하나의 쌍들이 모두 클레임 입니다.

 

인증시 토큰에서 실제로 사용될 정보를 가지고 있고, 여러개의 클레임은 JWT 토큰 생성시 개발자가 어떤 클레임을 넣을지 정한 후 자유롭게 커스텀 할 수 있습니다. 

 

페이로드에 들어가는 클레임들은 모두 암호화가 되어 있지 않기에 민감한 정보를 담지 않는게 좋습니다. 단순하게 "식별" 을 위한 정보를 넣는게 좋다고 합니다.

 

---

 

Signature (서명)

 

Signature 은 JWT 의 가장 마지막 부분이고 암호화 되어 있는게 특징입니다.

 

Header 에서 정의한 알고리즘 방식(alg) 를 이용해 암호화를 하게 됩니다. Hader 와 Payload 는 단순히 인코딩된 값이기에 제3자가 조작할 수 있지만 Signature 는 서버측에서 관리하는 비밀키가 유출되지 않는 이상 정보를 조작할 수 없습니다. 

 

Signature 는 이런한 암호성을 가지기에 토큰의 위변조 여부를 확인하는데 사용됩니다.

 

 

OAuth2 가 무엇일까?

 

 

OAuth2 는 제 3자 클라이언트 (사용자) 가 사용자의 접근 권한을 위임 받을 수 있는 프로토콜입니다. 많은 서비스들이 OAuth2 프로토콜을 사용해 사용자가 로그인하는 과정을 거치지 않고 빠르고 편리하게 서비스를 사용할 수 있게 제공합니다.

 

OAuth2 는 사용자의 인증보단 접근 권한을 위임 하는데 중점을 두고 있습니다. 

 

OAuth2 의 동작과정을 알아보기 전 사용되는 용어를 알아야 합니다.

 

OAuth 2.0 용어

 

구분	설명
Resource Server (리소스 서버)	OAuth 2 서비스를 제공하고 Resource 를 관리하는 서버다. (Google, Naver, Kakao 와 같은 회사에서 제공하는 서버) 클라이언트
Resource Owner (리소스 소유자)	어플리케이션을 이용하려는 사용자
Client (클라이언트)	Resource Server 의 API 를 사용해 정보를 가져오려는 애플리케이션 서버 입니다. 우리가 개발할 서버가 바로 Client 라는 용어로 정의됩니다.
Authorization Server (인증 서버)	Client 가 Resource Server 의 서비스를 사용할 수 있게 인증하고 토큰을 발행해 주는 서버입니다. 사용자(Resource Owner) 가 Authorization Server 로 정보를 넘겨 Authorization Code 를 발급 받는다.
Access Token	Access Token 으로 Resource Server 에 요청해 개인정보를 받습니다.
Refresh Token	해당 토큰으로 AccessToken 을 재발급 합니다.

 

 

 

 

 

동작 과정

https://comumu.tistory.com/manage/newpost/74?type=post&returnURL=https%3A%2F%2Fcomumu.tistory.com%2F74

 

1 : 사용자가 클라이언트에게 접근 및 로그인을 요청합니다. (소셜 로그인 클릭)

2 : 사용자가 Authorization Server 로 로그인을 요청합니다.

3 : Authorization Server 가 사용자에게 로그인 페이지를 제공합니다.

4 : 사용자가 ID, PW 와 같은 개인정보를 입력해 Authorization Server 에 요청 후 유효성을 확인합니다.

5 : Authorization Code 를 사용자에게 발급합니다.

6 : 사용자가 서비스에게 Redirect Callback URL 로 Authorization Code 를 담아서 요청합니다.

7 : 서비스가 Authorization Code 를 사용해 Authorization Server 로 인증을 요청합니다. (Access Token 발급 요청)

8 : Authorization Server 가 AccessToken 을 발급해 Client 로 넘겨주고 Client 는 DB 에 AccessToken 을 저장합니다.

9 : Client 에서 사용자의 인증완료와 로그인처리를 합니다.

10 ~ 13 : Resource Server 로 부터 발급 받은 AccessToken 을 사용해 사용자의 정보를 요청하고 조회할 수 있습니다.

 

 

직접 코드로 구현해보기 전까진 전부 이해하기 힘들었습니다.. 다음 포스팅 부턴 실제 프로젝트에 적용해보며 연습해봅시다!