인가 Authorization
사용자가 서버에 로그인 하면 해당 사용자가 맞는지 확인하는 과정이 인가이다.
인가가 필요한 이유는 바로 HTTP 특징 때문.
HTTP의 특징
-
request / response - 요청과 응답
-
stateless한 성질 - 저장하지 않는 성질
서버는 사용자가 로그인 했을 경우, 로그인 했다는 것을 어떻게 알 수 있을까?
headers에 메타데이터를 보내서 확인한다.
이 메타정보를 바로 JSON Web Token - 일명 JWT라고 한다.
토큰의 보안을 강화하는 방법
-
발행된 토큰이 특정 ip에서만 가능하도록 제한
-
브라우저의 아이디로 추가 검증
-
로케이션을 둔다던지
-
한번 인가된 토큰은 일회성으로 제한
-
로그인 할 때마다 토큰이 리프레시
JWT(JSON Web Tokens)
유저가 로그인에 성공한 후에는 access token이라고 하는 암호화된 유저 정보를 첨부해서 request를 보내게 된다.
// 유저 로그인:
POST /auth HTTP/1.1
Host: localhost:5000
Content-Type: application/json
{
"username": "joe",
"password": "pass"
}// access token:
HTTP/1.1 200 OK
Content-Type: application/json
{
"access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZGVudGl0eSI6MSwiaWF0IjoxNDQ0OTE3NjQwLCJuYmYiOjE0NDQ5MTc2NDAsImV4cCI6MTQ0NDkxNzk0MH0.KPmI6WSjRjlpzecPvs3q_T3cJQvAgJvaQAPtk1abC_E"
}그러면 서버에서는 access token을 복호화 해서 해당 유저 정보를 얻게 된다.
- 예를 들어
access token인
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZGVudGl0eSI6MSwiaWF0IjoxNDQ0OTE3NjQwLCJuYmYiOjE0NDQ5MTc2NDAsImV4cCI6MTQ0NDkxNzk0MH0.KPmI6WSjRjlpzecPvs3q_T3cJQvAgJvaQAPtk1abC_E를 복호화 하면 다음과 같은 정보를 얻는다:
{
user_id = 1
}복호화해서 얻은 유저 아이디를 통해 해당 유저가 누군지 알 수 있다.
이런 절차의 목적은
-
해당 유저가 매번 로그인 해도 되지 않도록 하는 것이다.
-
access token을 생성하는 방법은 여러가지가 있는데, 그 중 가장 널리 사용되는 기술중 하나가 바로
JWT(JSON Web Tokens)이다. -
JWT는 말 그대로 유저 정보를 담음 JSON 데이터를 암호화 해서 클라이언트와 서버간에 주고 받는 것이다.
JWT의 구조
header
- 토큰의 타입과 해시알고리즘 정보
- 헤더의 내용은 BASE64 방식으로 인코딩해서 JWT의 가장 첫 부분에 기록
ex) {“alg”: “HS256”, “typ”: “JWT”}
payload
- exp와 같이 만료시간을 나타내는 공개 클레임
- 클라이언트와 서버간 협의하에 사용하는 비공개 클레임
- 위의 두가지 요소를 조합하여 작성한뒤 BASE64 인코딩하여 두번째 요소에 위치
ex) { “user-id” : 1, “exp”: 1539517391 }
signature
-
JWT가 원본 그대로라는 것을 확인할 때 사용하는 부분
-
BASE64URL 인코드된 header 와 payload 그리고 JWT secret(별도 생성)을 헤더에 지정된 암호 알고리즘으로 암호화하여 전송 (복호화 가능)
-
프론트엔드가 JWT를 백엔드 API 서버로 전송하면 서버에서는 전송받은 JWT의 서명부분을 복호화하여 서버에서 생성한 JWT가 맞는지 확인
-
주의 : header와 payload는 BASE64 인코딩한 것이므로(암호화아님) 누구나 원본을 볼 수 있으니 개인정보를 담아서는 안됨
생성된 JWT의 예시
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpZCI6Mn0.TqNLDeEa gjSeV6UozaejHx-xOWuzu_6XPHFRvW76Ong
Token vs ID/PW
-
성능
- 무거운 bcrypt 없이 간단한 hash로 가능
-
클라이언트단 storage
- 쿠키처럼 실제 ID/PW를 저장하지 않음
- 해당 사이트에서만 이용 가능함
Authorization 절차
-
Authentication 절차를 통해 access token을 생성한다.
access token에는 유저 정보를 확인할 수 있는 정보가 들어가 있어야 한다.
ex) user id -
유저가 request를 보낼때 access token을 첨부해서 보낸다.
-
서버에서는 유저가 보낸 access token을 복호화 한다.
-
복호화된 데이터를 통해 user id를 얻는다.
-
user id를 사용해서 database에서 해당 유저의 권한(permission)을 확인하다.
-
유저가 충분한 권한을 가지고 있으면 해당 요청을 처리한다.
-
유저가 권한을 가지고 있지 않으면 Unauthorized Response(401) 혹은 다른 에러 코드를 보낸다.
