2주차 - 토큰 기반 인증(OAuth 2.0, JWT)

[옛날 이야기 - 세션 기반 인증]

예전에는 사용자의 로그인 상태를 서버가 전부 가지고 있었어요.

서버의 세션에 사용자 정보를 넣고 이 사람이 로그인을 했다 안했다를 전부 기록하고 기억했습니다.

이 세션은 서버의 메모리나 데이터베이스 등에 저장해두는데, 로그인한 사용자가 많아지면 서버에 부하가 많이 오겠죠? 그렇다고 서버를 여러개 놓자니 관리가 까다로워지고요.

→ 그래서 최근에는 오늘 배울 토큰 기반 인증 방법을 많이 사용해요!

 

- OAuth 2.0

: 외부 서비스의 인증 및 권한 부여를 관리하는 프레임워크입니다.

→ Open Authentication, Open Authorization라고 해요. (인증과 허가를 포함해요!)

 

1) OAuth 동작 방식 (간단 ver)

1. 클라이언트와 서버 사이에 인증(로그인)을 하면 서버가 access_token 을 줍니다.
2. 클라이언트는 access_token을 이용해서 API 요청을 할 수 있어요.
3. 서버는 API 요청을 받고, access_token을 가지고 권한이 있나 없나 확인해서 결과를 클라이언트에 보내줍니다.

2) OAuth 동작 방식 (외부 서비스 엮음 ver)

유저가 구글 로그인을 하는 상황이라고 가정하고 생각해봅시다!

공식적으로 쓰는 용어와 함께 가정해볼게요. :)

 

여기서 구글은 유저의 정보도 가지고 있을거고, 로그인을 검증도 해줄거예요.

그러니까 구글은 Resource Server(자원 서버) + Authorization server(권한 서버)겠죠!

유저는 그 정보를 가진 사람이니 Resource Owner(자원 소유자)라고 부릅니다.

(구글에서 주는 유저 정보는 Resource(자원)이라고 부릅니다.)

1. 유저가 구글 로그인을 합니다.
   • 자원 소유자가 자원서버에 권한 요청을 한거죠!
2. 구글은 로그인할 때 유저가 입력한 정보(아이디, 비밀번호 등)을 보고클라이언트(우리 웹사이트!)에 접근 권한을 줍니다.
3. 클라이언트는 이 권한을 가지고 Authorization server(권한 서버)에 access_token을 요청합니다.
4. 클라이언트는 이 access_token을 가지고 구글에서 유저 정보를 가져올 수 있어요.
5. 구글은 클라이언트가 보낸 access_token을 가지고 권한이 있나 없나 확인해서 결과를 클라이언트에 보내줍니다.

 

- JWT(Json Web Token)

: 토큰의 한 형식입니다. 데이터가 JSON 형태로 이루어져 있는 토큰입니다.

 

1) 생김새 : [header].[payload(내용)].[sinature(서명)]

• header: 토큰 타입과 암호화 방식 정보가 들어갑니다.
• payload: 토큰에 담을 정보가 name: value 쌍으로 들어갑니다.
• signature: 서명 정보입니다. secret key를 포함해서 header와 payload 정보가 암호화 되어 들어갑니다.

2) 동작 방식 : 토큰 기반 동작 방식대로 움직입니다.

• 유저가 로그인을 시도하면,
• 서버가 요청을 확인하고 secret key를 가지고 access_token을 발급합니다.
• 클라이언트에 JWT를 전달하고
• 클라이언트는 API 요청을 할 때 Authorization header에 JWT를 담아서 보냅니다.
• 서버는 JWT의 서명을 확인하고 payload에서 정보를 확인해서 API 응답을 보냅니다.

 

- JWT vs OAuth?

: JWT와 OAuth는 로그인에 많이 쓰이는 두 인증 방식입니다.

뭘 택할지 자주 고민하게 되지만 사실 비교하긴 조금 애매해요.

JWT는 토큰의 한 형식이고 OAuth는 프레임워크거든요. (OAuth에서 토큰으로 JWT를 사용할 수도 있고요. 🙂 )

 

- Authorization 헤더

: HTTP Authorization 헤더에 대해 더 알고 싶다면 이 문서(링크)를 참고해주세요!