인증 총 정리 :: 1. 내가 생각하는 Auth Flow Best Case (feat. OpenIDC)

인증 Best Case

기본 flow (OpenIDC)

Best Case라고 생각하는 인증 flow(OpenIDC)를 먼저 설명하겠습니다.

먼저, Auth Service가 타 서비스가 아닌 자사의 서비스일 때는 OAuth 기반의 flow가 필요없이 다음과 같이 시퀀스 다이어그램이 그려집니다. (타 서비스일 경우 OAuth 보기)

auth flow

1. Client가 id(username)와 password를 입력하여 로그인합니다. 로그인 요청은 BFF → Server → Auth Service로 전해집니다.
2. 전달된 id와 password로 Auth Service에서 인증합니다.
3. 인증에 성공하면 access token, refresh token, id token 를 Server로 전달합니다.
4. Server는 id token 을 decode하여 userInfo를 얻고, id token 은 따로 저장해둡니다.
5. Server가 BFF Server에 userInfo와 token들(access token, refresh token)을 전달합니다.
6. id token 까지 내려주어 BFF Server가 가지고 있으면서 decode하여 userInfo를 내려줄 수도 있습니다.
7. BFF Server가 refresh token 를 자체 저장합니다.
   1. refresh token 자체를 내려주고 Client에서 http-only 쿠키로 저장하는 경우도 있습니다.
   2. 대부분 User가 한정되어있는 백오피스에서 이러한 방식을 사용합니다. refresh token이 공개 되어 있더라도 쿠키를 통해 통신해야 하기 때문에 Server의 api endpoint를 모르면 공격할 수 없습니다.
   3. refresh token이 탈취될까 걱정된다면 BFF에서 (key : index(or hash value), value : refresh token)인 인덱스 DB와 통신하면서 key에 해당하는 값을 Client에 내려줘 쿠키로 저장하면 됩니다. 어차피 Client에서는 인덱스 DB의 경로와 접근 방법을 모르기 때문에 refresh token이 안전합니다.
   4. (위의 flow에서는 이 방법을 가정합니다.)
   5. 같은 방식으로 인덱스 DB와의 통신을 Server에서 하는 방법도 있습니다.
8. refresh token을 저장하는 방식은 여러 가지이며 다음과 같습니다.
9. response의 header에 의해 access token 이 Client의 쿠키에 저장됩니다. 더해서 userInfo와 refresh key가 함께 내려옵니다.
   1. access token 을 쿠키로 저장하지 않고 그냥 저장한 후, Request Header에 직접 Authorization 속성으로 담아 보낼 수도 있습니다.
10. Client에서 access token 이 담긴 cookie를 포함해서 api 요청을 보냅니다. 요청은 BFF → Server를 거칩니다.
11. Server에서 Auth Service에 해당 access token이 유효한 지 검증을 요청합니다.
12. Auth Service에서 검증 후 (access token이 이상한 값 이거나 유효기간이 지난 등의 이유로) 실패가 나왔다고 가정해 봅시다. Auth Service → Server → BFF Server → Client 로 검증 실패를 내려줍니다.
13. Client는 인증 실패를 확인한 후 BFF에 보유하고 있던 refresh key 와 함께 access token 재발급 요청을 보냅니다. 해당 요청은 BFF에서 인덱스 DB에 의해 refresh token 으로 변경되어 Server를 거쳐 Auth Service로 전달됩니다.
    1. 만일 Client의 http-only 쿠키로 넘어온다면 다른 과정없이 바로 요청을 전달하면 됩니다.
    2. BFF Server에서 인덱스 DB와 통신한다면 전달 받은 refresh key를 이용해 refresh token을 찾아 Server에 전달합니다.
    3. Server에서 인덱스 DB와 통신한다면 refresh key 를 Server에 전달하면 됩니다.
14. Auth Service에서 refresh token의 검증을 거칩니다.
15. 검증에 성공하면 Auth Service에서 Server로 access token 을 전달합니다.
16. Server에서 BFF Server로 access token 과 userInfo 를 전달합니다.
17. BFF Server는 Client에 userInfo와 access token을 내려줍니다.
18. Client는 api 요청을 access token 이 있는 cookie와 함께 보냅니다. 요청은 BFF Server를 거쳐 Server로 갑니다.
19. Server에서는 Auth Service에 access token 에 대한 검증 요청을 합니다.
20. Auth Service에서 인증 성공이 내려오면 response가 Client에까지 내려갑니다.

 

인증 및 인가

OpenIDC 에서는 access token으로 인증(특정 User임을 증명)하고, id token으로 인가(어떤 권한이 있는지를 확인)합니다.

 

토큰 기반의 인증

위처럼 토큰을 이용하여 인증하는 flow를 토큰 기반의 인증이라 일컫습니다.

토큰은 다음의 3가지 종류가 있습니다.

• access token : 사용자 인증 목적
• refresh token : access token 재발급 목적
• id token : 정보 전달의 목적

access token은 사용자를 인증하며 쿠키에 주로 저장되기 때문에 탈취 시 빠르게 무효화할 수 있도록 유효시간을 짧게 설정합니다. 대신 refresh token을 이용하여 access token 을 무한정 재발급 할 수 있으므로 refresh token 이 탈취되면 위험합니다.

 

refresh token의 저장 방법

따라서, 6번 과정에서 보았듯이 refresh token이 다양한 방법으로 저장됩니다.

1. refresh token 자체를 Client에서 http-only 쿠키로 저장
2. BFF에서 (key : index(or hash value), value : refresh token)인 인덱스 DB와 통신하면서 key에 해당하는 값을 Client에 내려줘 쿠키로 저장
3. 2와 같은 방식이지만 인덱스 DB와의 통신을 Server에서

 

JWT

토큰은 주로 JWT 방식으로 변환되어 Client에 저장됩니다.

 

JWT는 JSON 객체를 안전하게 주고 받기 위해 만들어진 방식입니다. JWT는 데이터를 감추기 위해서가 아니라, 데이터가 바뀌지 않고 입증된 사용자에 의해 보내졌음 을 증명하기 위해 만들어졌습니다. JWT를 이용하면 User를 서버 session에 저장하지 않고도(User마다 Session을 유지하지 않고도) 해당 User가 적합한 지 인증 가능합니다.

 

JWT는 3개의 파트로 구성되어있습니다.

header.payload.signature

• Header : JWT라는 type과 사용하는 해시 함수 알고리즘이 기재되어 있습니다.
• Payload : 실제 데이터가 들어있으며, 선택적으로 expire time 등이 들어있습니다. 빠른 request 처리를 위해 짧게 구성되어있으며, 쉽게 decode 될 수 있으므로 민감한 정보는 넣으면 안됩니다.
• Signature : header와 payload 데이터의 합입니다. JWT 구조에서 가장 중요한 파트로 쉽게 decode 되지 않습니다. header와 payload가 바뀌지 않았는 지 체크하고 private key를 이중 체크하기 때문입니다.