문자열로 된 KEY를 사용자에게 제공한다. API를 호출할때마다 메시지에 이 키를 포함한다.
API 서버는 이 키를 확인한후 인증 절차를 거친다.
API 토큰을 발급하는 방식. ID, PW로 사용자를 인증한후 API 호출에 사용할 토큰을 발급한다. API 토큰으로 사용자를 인증한다.
API 토큰을 사용하는 이유는 id, pw는 바뀔수 있고, id, pw를 계속 사용하면 탈취당할 가능성이 높아지기 때문에 별도로 발급해서 사용한다.
일반적인 서비스에서는 필요 없음. API를 외부에 공개하면서 ID, PW를 보호하는데 필요한 서비스이기 때문에 API를 외부에 적용할때는 고려해야 한다.
Claim 기반의 토큰 방식 OAuth가 많이 언급되는데 최근에는 JWT 표준이 인기가 많다.
OAuth는 토큰을 기반으로 사용자와 연관된 권한을 구별하여 이를 허용해준다. 서버에서 토큰으로 내부 DB를 뒤져 사용자의 권한 정보들을 매 호출마다 조회해서 확인해야 한
{ "id":"daniel", "role": ["admin", "user"], "company": "light one" }
Json 자체를 토큰으로 사용하는것이 claim 기반의 토큰 방식이다.
장점은 Claim 안에 있는 정보로 사용자 권한을 허용해 줄 수있는것이다.
Claim JSON을 Base64로 인코딩한다
누군가가 메시지를 변조하는것을 막기 위해 HMAC를 사용한다. 원본 메시지에서 해시 값을 추출하고 비밀키를 이용해서 암호화 한후 토큰뒤에 붙인다
JWT가 어떤 서명 방식을 사용했는지 토큰의 맨 앞부분에 덧붙인다.
{"alg":"HS256", "typ":"JWT"}
이를 base64로 인코딩한후 토큰 앞에 붙인다
전체 메시지 포맷은 {서명방식}.{JSON Claim}.{JSON Claim 서명}
문제점
길이 문제 : 항상 토큰이 API에 붙어 다니기 때문에 헤더 길이가 그만큼 늘어난다. 전송 데이터량이 많아진다
토큰 수정, 폐기 불가 : 토큰내에 모든 정보를 가지고 다니기 때문에 한번 발급되면 변경이 불가능하다. JWT는 만료 시간을 명시적으로 두고, Refresh Token등을 이용해서 토큰을 재발행하도록 해야한다.
암호화 : Claim에 대한 정보를 암호화하지 않는다. 이를 보완하기 위한 JWE가 있다