[WEB] 인증 방식 - OAuth(Open Authorization), JWT(Json Web Token)

API Key

• 서비스 확대로 기능들이 분리되면서, Module이나 Application들간의 공유와 독립성을 보장하기 위한 기능들이 생겨남
• 동작 방식
  • 1. 사용자는 API Key를 발급받는다.
  • 2. 해당 API를 사용하기 위해 Key와 함께 요청을 보낸다.
  • 3. Application은 요청이 오면 Key를 통해 User정보를 확인해서 누구의 key인지 확인
  • 4. 해당 key의 인증과 인가에 따라 데이터를 사용자에게 반환
• 문제점 : key가 유출되면 대비하기 힘들다. -> key 업데이트의 번거로움

 

 

OAuth(Open Authorization)

• 인터넷 사용자들이 비밀번호를 제공하지 않고 
• 다른 웹 사이트 상의 자신들의 정보에 대해
• 웹 사이트나 애플리케이션의 접근 권한을 부여할 수 있는 개방형 표준
• 간편 로그인
• API Key 단점 보완
• 사용 용어
  • 사용자 : 계정을 가지고 있는 개인
  • 소비자 : OAuth를 사용해 서비스 제공자에게 접근하는 웹사이트 or 애플리케이션
  • 서비스 제공자 : OAuth를 통해 접근을 지원하는 웹 애플리케이션
  • 소비자 비밀번호 : 서비스 제공자에서 소비자가 자신임을 인증하기 위한 키
  • 요청 토큰 : 소비자가 사용자에게 접근 권한을 인증받기 위해 필요한 정보
  • 접근 토큰 : 인증 후에 사용자가 서비스 제공자가 아닌 소비자를 통해 보호 자원에 접근하기 위한 키 값
  • 토큰의 종류
    • Access Token : 만료시간 존재. 다시 요청 가능
    • Refresh Token : 만료되면 다시 처음부터 진행
• 문제점
  • Token이 규칙 없이 발행되기 때문에 증명확인이 필요하다.

인증 과정

1. 사용자가 App의 기능을 사용하기 위한 요청을 보낸다.

2. App은 해당 사용자가 로그인이 되어있는지 확인

3. App은 사용자가 로그인이 되어있지 않으면 사용자를 인증서버로 Redirection

4. 간접적으로 Autorize 요청을 받은 인증 서버는 해당 사용자가 회원인지 인증서버에 로그인 되어있는지 확인

5. 사용자가 최초의 요청에 대한 권한이 있는지 확인(GRANT)

6. 사용자가 Grant 요청을 받게 되면 사용자는 해당 인증정보에 대한 허가를 준다.

7. 인증서버에서 인증과 인가에 대한 과정이 모두 완료되면 App에게 인가코드

8. 인가코드의 유효시간은 짧기 때문에, App은 해당 코드를 Request Token으로 사용하여 인증 서버에 요청을 보낸다.

9. 인증서버는 자신의 저장소에 저장한 코드와 일치한지 확인하고 실제 리소스에 접근하게 될 Access Token 발급

10. 이제 App은 Access Token을 사용해서 업무 처리 가능

 

 

JWT(JSON Web Token)

• 토큰 작성에 대한 규약
• 웹 표준으로, 두 개체에서 JSON 객체를 사용하여 가볍고 자가수용적인 방식으로 정보를 안정성 있게 전달
• 인증 여부 확인을 위한 값, 유효성 검증을 위한 값 그리고 인증 정보 자체를 담고 있기 때문에 인증 서버에 묻지 않아도 사용 가능
• 문제점
  • 토큰 자체가 인증 정보를 가지고 있기 때문에 민감한 정보는 인증 서버에 다시 접속하는 과정이 필요하다.

 

JWT 구성요소

 

• 3가지 문자열로 구성
• 1. header(헤더) : JWT 서명에 사용된 알고리즘을 담는다. 
  • typ : 토큰의 타입
  • alg : 해싱 알고리즘 
• 2. payload(정보) : 토큰에 담긴 주체들을 담는다. 
  • 토큰을 담을 정보
  • iss : 토큰 발급자 (issuer)
  • sub : 토큰 제목 (subject)
  • aud : 토큰 대상자 (audience)
  • exp : 토큰 만료 시간(expiration)
  • nbf : 토큰의 활성 날짜(Not before)
  • iat : 토큰이 발급된 시간(issued at)
  • jti : JWT 고유 식별자
• 3. signature(서명) : 헤더와 페이로드를 각각 base64로 인코딩하고 콤마로 이어 붙인다. 그리고 헤더에 있는 알고리즘으로 암호화된 값을 담는다.
  • 클라이언트에서 받은 토큰의 데이터 조작 여부를 확인하는 곳 
  • 헤더의 인코딩 값과 정보의 인코딩 값을 합친 후 주어진 비밀키로 해쉬하여 생성한다. (header+payload+salt = hash)
  • 이렇게 만든 해쉬는 base64 형태로 나타낸다.
  • base64 : 8비트 이진 데이터를 문자 코드에 영향을 받지 않는 공통 ASCII 영역의 문자들로만 이루어진 일련의 문자열로 바꾸는 인코딩 방식. 통신과정에서 binary data 손실을 막기 위해 사용한다.

 

로그인 인증과 JWT

• 유효기간이 짧은 토큰은 사용자 입장에서 자주 로그인을 해야해서 번거롭다.
• 유효기간이 긴 토큰은 편하지만 토큰을 탈취당할 약점이 있다.
• Refresh Token : 위의 단점을 보완하기 위해 사용
  • Access Token의 유효기간이 만료되었을 때, Refresh Token이 새로 발급
  • Refresh Token이 만료되면, 새로 로그인
• 토큰 저장 장소
  • Access Token : 클라이언트(cookie)
  • Refresh Token : 서버(DB)

 

 

 

 

JWT와 OAuth 2.0의 차이

- 둘 다 인증 방식이라는 공통점이 있지만, 서로 목적이 다르다.

- OAuth 2.0 : 하나의 플랫폼의 권한(아무 의미없는 무작위 문자열 토큰)

다양한 플랫폼에서 권한을 행사할 수 있게 해줌으로써 리소스 접근이 가능하게 하는데 목적을 두고있다.

 

- JWT는 Cookie, Session을 대신하여 의미있는 문자열 토큰

로그인 세션이나 주고받는 값이 유효한지 검증할 때 주로 사용