HTTP의 인증방식에 대하여(Basic Authentication, Bearer Token Authentication, OAuth)

출처: https://www.youtube.com/watch?v=USu2W2N1Q4Q&list=PLbq5jHjpmq7q-Td2jOXtpf7SD5c53RqXh&index=9  

좋은 글: https://engineerinsight.tistory.com/69  

정말 좋은 글:  https://engineerinsight.tistory.com/163

어떠한 내가 모르는 내용이 나왔을때 그것을 처음부터 검색해 보려하면 한숨부터 나오고 힘들다는 감정이 생기는 것 자체가 잘못된 방향으로 가고 있는 것이다. 그럴 때는 잠시 리프레쉬하는 시간을 가지고 다시 시작해야 한다. 잠시 쉬라는 것이다. 

사실 유튜브영상의 이 내용을 쉬지 않고 익숙히 하기는 힘들었고 몇번의 리프레쉬 끝에 어떻게 하면 이렇게 접해보지 않은 정보를 찾아 나갈수 있을까? 를 고민했다. 영상에서 큰 맥락에서 이 내용은 HTTP의 인증방식에 관한것이고 그 인증방식의 종류에 대해 설명을 하는 것 같아 인증방식의 첫번째에 해당하는 것을 구글에 검색어로 "http basic authentication" 이라고 검색하였더니 아래와 같은 훌륭한 글을 볼수 있었다. https://engineerinsight.tistory.com/69    

 

HTTP의 인증방식 

1. Basic Authentication: 가장 기본적인 인증방식으로 사용자 이름과 비밀번호를 Base64로 인코딩하여 HTTP의 Authorization헤더에 포함하여 전송됨. 매우 안전하지 않습니다. SSL/TSL와 함께 사용됩니다. 일반적인 HTTP 헤더에 표시될 때에는 Authorization: Basic ~~~형식으로 인코딩된 내용이 전송됨.  

(  https://engineerinsight.tistory.com/69 
이 글보면 동영상에서 말하는 위 내용이 무슨 내용인지 다 이해됨) 

 

2. Bearer Token Authentication: HTTP의 Authorization 헤더에 토큰을 포함하여 전송됨. 기본적으로 JWT를 사용하여 인증처리를 함(주의. Bearer토큰과 JWT토큰은 같은 것이 아니다). 간단한 방식으로, 상태를 유지하지 않고 확장성이 높다(JWT는 상태를 유지하지 않고 세션은 상태를 유지한다). 단점으로는 토큰 노출 위험이 있고 토큰 관리가 힘들다는 부분이 존재함.  (Bearer Authentication은 Token Authentication이라고도 불림. 모두 http 인증방식이다)

리퀘스트(Request) 헤더에  Authorization: Bearer ~~~ 형식으로 전송됨.

Bearer Token 참고 글: https://www.ssemi.net/what-is-the-bearer-authentication/

Bearer Token 참고 글2: https://djlee118.tistory.com/830

Bearer토큰은 OAuth 2.0프로토콜에서 사용되는 토큰이다. 따라서 인증된 사용자를 대신하여 API에 접근할 수 있는 권한을 부여한다. Bearer토큰은 JWT토큰과 달리 사용자 정보를 포함하지 않기 때문에 API에 접근할 때마다 사용자 정보를 함께 전달해야 한다. 이는 JWT토큰보다는 불편하지만 보안 측면에서는 더욱 안전하다.

JWT도 payload부분에 많은 정보를 포함할 수 있지만 민감한 개인 정보 같은 경우는  디코딩하여 누구나 볼수 있기대문에 중요정보를 포함하지는 않는다. 하지만 가벼운 사용자 정보 같은 경우는 JWT에 실려 다닌다.

우리는 프로젝트에서 2. Bearer Token 인증방식을 사용하게 됩니다. 

 

3. OAuth방식: 토큰기반 인증 방식으로 사용자가 직접 자격을 증명하지 않고 미리 인증을 받아서 토큰을 발급받고 이 토큰을 이용하여 API를 요청하는 방식임. 보통 Bearer토큰과 함께 사용된다. 우리가 흔히보는 카카오, 네이버, 깃헙, 페이스북 로그인을 할때 OAuth방식이 사용된다(흔히 말하는 소셜로그인을 할때 사용되는 것이 OAuth이다. 참고로 소셜로그인이라함은 내가 어떤 서비스를 이용하고자 할때 네이버나 카카오 아이디를 가지고 로그인 할 수 있는 것을 소셜로그인이라고 한다).

OAuth에 대한 영상: https://www.youtube.com/watch?v=Mh3LaHmA21I

OAuth란 인증은 유저(client)가 직접하게 하고 인증과정에서는 내 서비스가 인증과정에서는 어떠한 것에도 관여하지 않는다. 반면 권한은 내 서비스가 받으며 유저(client)는 권한에 있어서는 어떠한 연관관계도 없다. 이와 같이 OAuth는 인증과는 관련없는 오직 인가를 위해서 탄생한 기술이다. OAuth공식 문서에는 OAuth의 주요 4가지 흐름이 있다. Authorization Code, Implicit, Resource Owner Password Credentials, Client Credentials. 이중 Authorization Code flow만 알아도 내가 구현하고자 하는 서비스는 충분히 구현할 수 있다.

OAuth란 간단하게 말해 우리의 서비스가 우리 서비스를 이용하는 유저의 타사 플랫폼 정보에 접근하기 위해서 권한을 타사 플랫폼으로부터 위임 받는 것 이다(즉 OAuth는 인가를 위한 기술 인증은 유저가 직접하고 권한(인가)는 client(내 서비스)가 받는다).

권한을 수여받은 client(우아한 캘린더)는 인가를 얻은 것과 같다.

 

유저가 구글에 ID, PW를 제공하여 인증과정을 거치는 동안 client인 우아한 캘린더는 인증과정에 관여하지 않는다.

인증이 성공했을시 권한(인가)은 client가 받고 유저는 이러한 권한과는 관련이 없다.

 

OAuth의 등장배경: https://hudi.blog/oauth-2.0/ 

 (정말 유익한 글이다. 글에서 말하는 클라이언트는 내가 만든 서비스 Resource owner는 나 자신, Authrization, Resource server는 권한을 부여해 줄수 있는 타사 플랫폼(구글, 야후등등)을 생각하면 된다)

OAuth개념과 과정 https://engineerinsight.tistory.com/163#%F0%9F%92%8B%C2%A0%EC%9D%B8%ED%8A%B8%EB%A1%9C-1

OAuth에 대한 좋은 글: https://engineerinsight.tistory.com/163

 

복습하자면 클라이언트는 로그인 페이지 url만 제공할 뿐 인증과정에 참여 하지 않는다. 오직 ResourceOwner와 Authorization Server가 인증을 처리함. 권한을 부여(인가)하는 과정에서도client와 Authorization server만 관여하지 ResourcceOwner는 관여하지 않는다.

 

(User-Agent는 ResourceOwner가 인증을 수행하게 해주는 매개체로 간단히 크롬 브라우저라고 생각하면 된다)

4. 그 외 방법으로는 API Key를 사용한 방식(키를 발급받아 키를 포함하여 서버에 전송하는 방식이다), 세션 기반 방식(Session based Authentication)(내가 알고 있듯이 HTTP프로토콜은 상태를 유지하지 않는다(Stateless)따라서 서버에서 생성된 세션ID를 클라이언트에 전달하면 매번 클라이언트가 요청할 때마다 이 세션ID를 쿠키안에 포함시켜 HTTP헤더 부분에 실려서 서버로 인증이되어 요청을 보내게 됨)등이 있다.