[Spring-boot]스프링시큐리티+OAuth1 인증 (1)

| 스프링 부트 시큐리티

-시큐리티 사용을 앞서 인증(Authentication)과 인가(Authorization)이라는 개념을 알아야 합니다.

 

인증(Authentication)

-사용자(클라이언트)가 애플리케이션의 특정 동작에 관하여 허락(인증)된 사용자인지 확인하는 절차
웹사이트 로그인을 인증이라 생각하면 됩니다.

-인증은 '증명하다'라는 의미로 예를 들어, 유저 아이디와 비밀번호를 이용하여 로그인 하는 과정 을 말합니다.

 

권한부여(Authorization)

-데이터나 프로그램 등의 특정 자원이나 서비스에 접근할 수 있는 권한을 허용하는 것
예를 들어 A는 VIP 회원이고, B는 일반 회원이라면 두 회원의 권한이 다르게 부여됩니다.

-인가는 '권한부여'나 '허가'와 같은 의미로 사용됩니다. 즉, 어떤 대상이 특정 목적을 실현하도록 허용(Access) 하는 것을 의미합니다.

 

즉, Web에서 인증은 해당 URL은 보안 절차를 거친 사용자들만 접근할 수 있다는 의미이고, 인가란 URL에 접근한 사용자가 특정한 자격이 있다는 것을 의미합니다.

• 인증 매니저(Authentication Manager)가 인증에 대한 실제적 처리를 담당합니다.
• 인증 매니저는 인증과 관련된 모든 정보를 UserDetails 타입으로 반환합니다.
• 이를 위해서는, 어떻게 관련 정보를 처리해야 하는지 판단할 UserDetailsService를 이용합니다.
• 따라서, 개발자가 해야 하는 것은 UserDetailsService 인터페이스를 구현하고 인증 매니저에 연결시켜주면 됩니다.

정리

• 모든 인증은 인증 매니저를 통해 이루어 집니다.
• 인증 매니저를 생성하기 위해서는 인증 매니저 빌드를 이용합니다.
• 인증 매니저를 이용해 인증이라는 작업을 수행합니다.
• 인증 매니저들은 인증/인가를 위한 UserDetailsService를 통해서 필요한 정보들을 가져옵니다.
• UserDetails는 사용자의 정보 + 권한 정보들의 묶음입니다.

 

 

 

 

| OAuth의 개념

OAuth1( Open Authorization, Open Authentication )

-애플리케이션(페이스북,구글,트위터)(Service Provider)의 유저의 비밀번호를 Third party앱에 제공 없이 인증,인가를 할 수 있는 오픈 스탠다드 프로토콜입니다.

-애플리케이션 API를 유저대신에 접근할 수 있는 권한을 얻을 수 있다.

 

 

| 왜 사용할까?

- OAuth가 사용되기 전에는 외부 사이트와 인증기반의 데이터를 연동할 때 인증방식의 표준이 없었습니다.

 때문에 기존의 기본인증인 아이디와 비밀번호를 사용하였는데, 이는 보안상 취약한 구조로 유저의 비밀번호가 노출될 가망성이 컸기 때문에 이 문제를 보안하고자 OAuth의 인증은 API를 제공하는 서버에서 진행하고, 유저가 인증되었다는 Access Token을 발급하였다. 그 발급된 Access token으로 Third party(Consumer)애플리케이션에서는 Service Provider의 API를 안전하고 쉽게 사용할 수 있게 되었습니다.

 

 

용어설명

User	Service Provider에 계정을 가지고 있으면서, Consumer앱을 이용하려는 사용자
Service Provider	OAuth를 사용하는 Open API를 제공하는 서비스 (facebook,google등)
Protected Resource	Service Provider로부터 제공되어지는 API 자원들
Consumer	OAuth 인증을 사용해 Service Provider의 기능을 사용하려는 애플리케이션이나 웹 서비스
Consumer Key	Consumer가 Service Provider에게 자신을 식별하는 데 사용하는키
Consumer Secret	Consumer Key의 소유권을 확립하기 위해 Consumer가 사용하는 Secret
Request Token	Consumer가 Service Provider에게 접근 권한을 인증받기 위해 사용하는 값. 인증이 완료된 후에는 Access Token으로 교환한다.
Access Token	인증 후 Consumer가 Service Provider의 자원에 접근하기 위한 키를 포함한 값
Token Secret	주어진 토큰의 소유권을 인증하기 위해 소비자가 사용하는 SecretOAuth의 WorkFlow

 

| OAuth의 WorkFlow

다음은 OAuth의 1.0의 WorkFlow입니다.

1.Consumer는 Service Provider로부터 클라이언트Key와 Secret을 발급 받아야 합니다.

( Service Provider에 API를 사용할것을 등록하는것과 동시에 Service Provider가 Consumer를 식별할 수 있게 해줍니다.)

( 즉, 각각의 카카오,네이버,구글,페이스북 등 식별키를 발급 받아야합니다.)

2. A에서 Request Token을 요청할 때  ( Consumer의 정보, Signature정보를 포함) 하여 B의 Request Token값을 발급받습니다.

3.Request Token을 발급 받은 뒤  C 와 같이 Consumer는 User를 Service Provider에 인증 사이트로 다이렉트 시킵니다.

유저는 그곳에서 Service Provider에 유저임을 인증합니다.

4.유저가 인증이 완료된 후  D 의 정보처럼 Consumer는  OAuth_token과 OAuth_verifier를 넘겨줍니다.

5.Consumer는 OAuth_token과 OAuth_verifier로 입증받은 뒤 E의 과정처럼 서명을 만들어 AccessToken을 요청합니다.

6.Service Provider는 받은 토큰과 서명들이 인증 되었다면 AccessToken을 F와 같이 넘겨줍니다.

7.Access Token 및 서명 정보를 통하여 Service Provider에 Protected Resource에 접근할 수 있게 됩니다.

참고

https://minwan1.github.io/2018/02/24/2018-02-24-OAuth/#-4