[Spring][Security][Oauth] 간단 정리

1.OAUTH 용어설명

RFC6749에 명시된 용어설명

Resource Owner(자원소유자) : 보호된 자원에 대한 액세스 권한을 부여할 수 있는 엔티티. 리소스 소유자가 사람인 경우 리소스 소유자는 최종 사용자.
Resource Server(리소스 서버) : 보호된 자원을 호스팅하는 서버. 액세스 토큰을 사용하여 보호된 리소스 요청에 응답.
Client(클라이언트) : 애플리케이션을 대신하여 보호된 리소스 요청을 하는 애플리케이션. 응용 프로그램 서버, 데스크톱 등이 될 수 있다.
Authorization Server(권한 서버) : 클라이언트에게 액세스 토큰을 발급하는 서버. 자원 소유자를 인증하고 리소스 접근 권한을 클라이언트에게 임명한다.

필자가 생각한 용어 설명

 
Resource Owner(자원소유자) : 자신의 리소스를 사용할 수 있게 Third-party Application(인증 서버 입장에서 Client Application)에게 사용을 허가하는 Third-party Application 사용자.
Resource Server(리소스 서버) : Resource Owner의 리소스를 가지고 있으며, 해당 리소스를 보호하는 Application. Client Application은 Authorization Server에게 발급받은 토큰을 이용하여 Resource Server에게 사용자 리소스를 받아 사용한다.
Authorization Server(인증서버) : Client Application이 Resource Owner의 리소스를 사용하기 위하여 Client Application에게 인가(토큰발급)해주는 역할을 하는 Application.
Client(클라이언트 애플리케이션) : Resource Server에 유지되고 보호되고 있는 Resource Owner의 리소스를 사용하는 Application. Authorization Server에게 적절한 인증을 통하여 토큰을 발급받고 해당 토큰을 이용해 Resource Server에서 보호된 Resource Owner의 리소스를 사용한다.
이 Application은 실제로 Resource Owner가 접속하여 사용중인 Application이며, 단순 Javascript Application 일수도 있고, Server로 기동되고 있는 Application일수도 있다.

---

2. Spring Security OAuth2.0 스키마 구성

클라이언트 등록과 관련된 데이터 테이블

create table oauth_client_details (
  client_id VARCHAR(256) PRIMARY KEY,
  resource_ids VARCHAR(256),
  client_secret VARCHAR(256),
  scope VARCHAR(256),
  authorized_grant_types VARCHAR(256),
  web_server_redirect_uri VARCHAR(256),

  access_token_validity INTEGER,
  refresh_token_validity INTEGER,
  additional_information VARCHAR(2000),
  autoapprove VARCHAR(256)
);

 
발급된 액세스 토큰을 저장하기 위한 테이블

예제는 JWT 토큰을 사용하므로 사용하지 않는다. 하지만 JWT토큰을 사용하지 않으면 해당 스키마를 사용한다.

create table oauth_access_token (
  token_id VARCHAR(256),
  token clob,
  authentication_id VARCHAR(256) PRIMARY KEY,
  user_name VARCHAR(256),
  client_id VARCHAR(256),
  authentication clob,
  refresh_token VARCHAR(256)
);

 
리프레시 토큰 발급을 위한 테이블

이 테이블도 역시 JWT 토큰을 사용하므로 사용하지 않는다.

create table oauth_refresh_token (
  token_id VARCHAR(256),
  token varchar(1000),
  authentication varchar(1000)
);

 
사용자(Resource Owner)의 승인을 저장하기 위한 테이블

create table oauth_approvals (
    userId VARCHAR(256),
    clientId VARCHAR(256),
    scope VARCHAR(256),
    status VARCHAR(10),
    expiresAt TIMESTAMP,
    lastModifiedAt TIMESTAMP
);

Authorization Code Grant Type에 사용될 인증코드를 보관하는 테이블

-- authorization code table
create table oauth_code (
  code VARCHAR(256), 
  authentication blob
);

OAUTH_CLIENT_DETAILS : 인증서버가 토큰을 발급해줄때, 등록된 유효한 클라이언트 애플리케이션이 맞는지 확인할때 사용되는 테이블이다.
client_id : 클라이언트를 구분하는 ID
resource_ids : API 버전 관리를 위해 oauth 토큰 제공자 서블릿과 리소스 서버를 분리하는 것을 고려할 때 더 명확해집니다. 
예를 들어 클라이언트 A(cA)가 api1에 액세스할 수 있고 클라이언트 B(cB)가 api2에 액세스할 수 있다고 가정하면 api1에 대한 리소스 서버 xml에 resource-id=api1을 지정하여 이 액세스를 적용한 다음 클라이언트 세부 정보를 구성합니다. 
cA의 경우 resourceIds="api1"이 있고 [cB,api2]의 경우도 마찬가지입니다.
client_secret : 클라이언트의 비밀번호로 OAuth2 서버에 요청할때 인증을 하기위한 용도로 사용한다.
authorized_grant_types: OAuth2 승인 방식의 종류 ..., ... 이런 형식으로,를 이용해서 구분한다.
access_token_validity : Access Token의 유효시간
refresh_token_validity : Refresh Token의 유효 시간
scope: 클라이언트로 발급된 Access Token의 Scope, 리소스에 접근 가능한 권한 구분은 , 으로한다
autoapprove: 권한코드 방식 같은 형태로 Access Token을 발급받을 때에는 사용자에게 scope 범위를 허가받는 화면이 나옵니다. 이 화면 자체가 나오지 않게 설정하는 값입니다. true하면 아래 화면이 나오지 않습니다.

OAUTH_APPROVALS : Resource Owner가 3rd-party 애플리케이션을 사용할때 마다, 해당 애플리케이션이 사용자의 리소스에 접근하는 것을 허락하겠냐라는 문구를 항상 띄워 줄수는 없을 것이다. 즉, 해당 테이블에는 최초로 Resource Owner가 3rd-party 애플리케이션에게 자신의 리소스 사용을 허락할때 Approval했다라는 데이터를 삽입한다. 그 이후로는 더 이상 Resource Owner에게 Approval 관련된 문구(팝업 등)을 띄우지 않을 것이다.

OAUTH_CODE : 오늘 진행해볼 Authorization Code Grant Type에 사용될 인증코드를 보관하는 테이블이다.

 

참고: https://coding-start.tistory.com/158