hyeoneee's blog

Backend 개발을 하다보면 인증방식을 결정해야 되는 순간이 꼭 있다.

서버와 서버간의 인증

서버와 모바일 서버

아니면 유저가 api서버를 가져다 쓸 때 의 인증 등등..

Backend 서버에서 제공해주는 정보를 가져다 쓸 때 인증이 필수 라고 볼 수 있다.

매 HTTP 요청마다 본인이 누구인지 알 수 있는 인증정보를 요청에 포함 시켜 요청해야한다. 

그런데 현업에서는 

다양한 아키텍쳐와 비지니스 로직이 있기 때문에

그러한 범위내에서 과연 수많은 인증 방식 중에서 어떤 인증 방법을 택하면 좋을까?

란 고민을 하게된다.

어떤 인증 방식을 택하면 좋을지? 를 결정하려면

당연히 어떤 인증방식이 있는지 알면 되지 않을까,,,,

란 답으로 시작해서 이번 포스팅을 하게 되었다.

(사실 보안이나 여러가지 개념이 너무너무 헷갈렸다 ^_^; 이러면서 배우는거쥐 뭐~)

그리고 Spring Security와 결부시켜서도 얘기해보겠다.

1. id + password 방식

가장~~~ 기본이 되고 간단한 방식이다.

그냥 DB에 있는 id와 password 를 요청에서 넣어준 값과 같은지 확인하는 방식이다.

여기서 한단계 더 나아가면 password를 암호화정도 하면 되겠다.

Spring Security에서도 이부분이 Default인 방식으로 볼 수 있다.

화면 Form에 그냥 id + password 를 담아서 넣어주면 인증이 된다.

2. Basic Auth

Basic Auth 도 간단한 방법인데

id:password 이 값을 base64로 인코딩한 값을 HTTP 헤더에 담아서보내주면 된다.

Authorization : Basic Base64(id:password)

ex) Authorization : Basic VGVycnk6aGVsbG8gd29ybGQ=

앞에 Basic을 붙여줘야한다!

중간에 패킷을 가로채서 이 헤더를 Base64로 디코딩 하면 id, password가 그대로 노출되기때문에 HTTPS를 쓰는 것을 권장한다.

3. JWT ( JSON Web Token)

JWT 는 . 을 구분자로 3가지의 문자열로 되어있습니다. 

aaaaaaa.bbbbbb.cccccc

header

payload

signature 

이 각각 세 파트를 각각 다른 방법으로 인코딩하여 HTTP 헤더에 정보를 담아서 넘겨준다.

참고

https://sanghaklee.tistory.com/47

4. OAuth 

방식은 다섯가지로 grant type이라고 한다.

요새 가장 많이 쓰는 방법이다.

참고

https://hyeonyeee.tistory.com/48

5. SAML ( Security Assertion Markup Language)

SSO( Sing Sign On) 이 필요할 때 많이 쓰는 인증방식이다.

즉 한번 로그인하면 다른 사이트나 다른 서버에서도 인증이 되는것이다.

하나의 인증으로 다 통합된다는것이다 

얼마나 편리한가,, 사실 이 안의 개념도 엄청 복잡하다.

따로 포스팅 해도 될정도 

ㅎㅎ간단히 보면 이정도 되겠다..

요새는 OAuth나 SAML을 가장 많이 쓰는거 같다.

그래서 그런지 이 두개를 비교하는 포스팅도 많다.

Spring Security는 그러면 이 모든 걸 다 제공한다^^

얼마나 방대한가.. ㅎㅎ;

사실 이 인증 방식과 Spring Security의 개념이 좀 혼동 되었었는데

이번에 정리 하고 넘어가서 좋다 ^^77

화이팅!

안의 포스팅은 차차.. 내용을 더 채워 나가도록 하겠다 

이전에 OAuth 2.0에 대해서 정리하는 글을 올렸었다.

그렇다면 Spring 에서 OAuth를 어떻게 구현할까?

그게 바로 Spring Security인데 그것에 대해서 알아보고자한다.

OAuth와 Spring Security는 여러번 보았는데

볼때마다 헷갈리고 다시 공부하는 느낌이다

부디 이번에 조금이나마 더 정리되길 바라며,,, 포스팅 시작한닷..ㅁ7ㅁ8

1. OAuth란?

Open Authorization , Open Authentication ( Open 인증 , Open 인가) 로

자신의 애플리케이션 서버의 데이터를 다른 Third Party 에게 공유나 인증을 처리해줄 수 있는 오픈 표준 프로토콜이다

즉,,

내 서버의 어플리케이션에 접근 하려면 인증을 거쳐야 하는데, 

이것의 표준이라고 생각하면 된다 ( 인증 & 인가)

이 개념이 궁금하면?

https://hyeonyeee.tistory.com/48

다음 포스팅을 참고하자.

2. Spring에서 OAuth 2.0?

OAuth가 오픈 표준 프로토콜이면 , 

Spring에서 OAuth를 구현하려면? 

Spring Security를 쓰면된닷,,!

3. Spring Security

이제 어느 부분을 구현해보면 되는지 알아보자.

다행히 Spring에서는 많은 소스를 제공해준다

엄청 복잡하게 공부할 수도있지만 우선, 나는 간단하게,, 이해해보겠다.

5가지 Grant Type중 

Resource Owner Password Credentials 방식으로 구현해보자.

여기서 크게 구현해야 될것은 세가지다.

1. AuthenticationProvider (Interface)

인증을 담당할 클래스를 구현

UserDetailServiceImpl에서 받아은 유저의 정보를 인증이 완료되면 Authentication 객체를 리턴해준다.

2. UserDetailService (Interface)

UserDetailService를 implements해서 custom UserDetailService를 만들어주어야한다.

user의 정보를 DB에서 받아온다.

3. Authentication Provider 추가하기 

 - SecurityConfig extends WebSecurityConfigurerAdapter

1번에서 만든 내가만든 인증 클래스를 ProviderManager에게 등록해주어야 한다.

참고)

HTTP Basic Auth 
가장 기본적이고 단순한 형태의 인증 방식으로 사용자 ID와 PASSWD를 HTTP Header에 Base64 인코딩 형태로 넣어서 인증을 요청한다.
예를 들어 사용자 ID가 terry이고 PASSWD가 hello world일 때, 다음과 같이 HTTP 헤더에 “terry:hello world”라는 문자열을 Base64 인코딩을해서 “Authorization”이라는 이름의 헤더로 서버에 전송하여 인증을 요청한다.
Authorization: Basic VGVycnk6aGVsbG8gd29ybGQ=
중간에 패킷을 가로채서 이 헤더를 Base64로 디코딩하면 사용자 ID와 PASSWD가 그대로 노출되기 때문에 반드시 HTTPS 프로토콜을 사용해야 한다.

en.wikipedia.org/wiki/Basic_access_authentication

https://jeong-pro.tistory.com/205

https://minwan1.github.io/2018/03/11/2018-03-11-Spring-OAuth%EA%B5%AC%ED%98%84/

https://spring.io/guides/topicals/spring-security-architecture

Oauth 2.0 는 무엇인가,, 알아보겠다 

이전엔 보통 open api를 이용할때 토큰을 받아와서 헤더값이 넣어주는 걸

즉, 토큰값을 받아오는걸 구현한 방식이 OAuth 라고 알고있었다

이것도 맞지만 더 자세히 알아보고자 한다 :-)

OAuth 2.0은 인가를 위한 프레임워크이다 

즉, 접근할 수 있는 권한을 주는 것이다.

여기서 헷갈리는 건 인증과 인가의 차이점이다.

인증은 Authentication : 본인여부를 확인 하는것  

인가는 Authorization : 서비스나 시스템에 접근 할 수 있도록 권한이 주어지는것 

OAuth 에는 네가지 역할이 있는데 그것은 다음과 같다.

4가지 실물

1. Resource Owner (사용자,나) : 서비스 이용자
2. Client (G마켓) : 서비스 제공자
3. Authorization Server (네이버-매표소)  : 토큰 발급 , 인가의 주체자
4. Resource Server (네이버-검표하는곳) : 토큰 확인 , 리소스 접근심의 문지기

이렇게 정리 할 수 있는데,

이해할 수 있도록 설명을 덧붙이자면..

사용자가 G마켓이라는 서비스를 이용하고자 하는데

G마켓을 가입할때 직접 가입하지않고 요새 많이 이용하는 네이버,페이스북, 구글 ID로 로그인 하는걸 

이용해서 가입하고자 한다

그러면 나라는 사용자는 Resource Owner이고

사용하고자 하는 서비스는 Client G마켓이다.

그리고 Authorization Server는 네이버나 인증을 도와주는 곳인데 이곳에서는 토큰만 발급해준다.

그이후, 발급한 토큰을 가지고 네이버에서 원하는 정보를 가져오는데

이 토큰을 확인하는 것이 Resource Server이다.

Grant Type (허가 유형) 
- Client가 Authorization Server에게 토큰 발행을 요청하는 유형

토큰을 발행하는 과정에서 다양한 정보를 주고 받는데,

어떤 정보를 주고 받는가?를 알아보겠다

1. Client_id, client_secret

- Id와 pw 역할

2. Redirect_uri

- Client 가 authorization server에 토큰 발행을 요청할 때 브라우저를 아예 redirect하는
경우도 있다. 토큰을 발행하는 과정에서 client는 필요 시, 인가 되었을 타이밍에 redirect되어야 할
Uri 정보를 authorization server에게 넘겨준다.

3. Response_type

- Client가 authorization server에게 토큰발행 요청 했을 때, 응답을 정의 (request에 대한 response를 정의)
- 5가지 grant type중 2가지 방식에서만 사용 ( Implicit , Authorization code)
○ Implicit : client-> Authorization server 최초요청만으로 토큰 발행 : response_type 은 token
○ Authorization code는 최초 요청에 code 리턴  

4. Grant_type

밑에서 자세히 설명하겠다 이건 

5. Scope (optional)

- Client가 접근 가능하도록 승인된 내 리소스의 범위
- Client가 authorization server에 토큰을 발급받은 이후, Resource Server를 지나서 실제
Resource에 접근하려고 할때, client별로 접근이 가능한 리소스를 구별해놓은 정보
( 예를들어 G마켓에서 네이버로 접근할때, 전화번호만가능, 생일까지 가능 이런?)

6. State (optional)

- Sate는 csrf 공격을 막기위한 정보 ???

Grant Type 5가지

1. Authorization code

- 가장 복잡한 방식이지만 가장 범용적으로 사용

- 인가 받은 code값을 토대로 토큰을 요청하는 방식
- Authorization Server에게 토큰을 발행 받기 위해 code값을 요청하고 이 code값을 
바탕으로 토큰을 발급 받는 방식
- Resonse_type = code

2. Implicit

- Client가 토큰발행을 요청하면 최초의 요청만으로 Authorization Server가 토큰 발행
- Response_type = token
- 쿼리스트링에 토큰 노출-> 모바일앱 또는 단말기에서 동작하는 웹 애플리케이션에서 주로 사용

3. Client Credentials

- 너무너무 신뢰가는 Client라서 Authorization Server가 묻지도 따지지도 않고 토큰 발행
- Resource Owner가 아닌 Client가 요청함

4. Resource Owner Password Credentials

- Resource Owner가 Client에게 id/password 전달함
- 토큰발행 요청하는 방식이 GET
- Resource Owner와 Client의 일급비밀(password/secret)을 모아서 토큰발행 요청 

5. Refresh 

- 최초에 token 받았을 때, 발급되는 refresh token으로 token 만료시, 재 발행 요청

- Authorization Code / Client Credentials Grant type 만 가능