WebMaster

ClientRegistration OAuth 2.0 또는 OpenID Connect 1.0 Provider 에서 클라이언트의 등록 정보를 나타낸다 ClientRegistration 은 OpenID Connect Provider의 설정 엔드포인트나 인가 서버의 메타데이터 엔드포인트를 찾아 초기화할 수 있다. ClientRegistrations의 메소드를 사용하면 아래 예제처럼 편리하게 ClientRegistration 을 설정할 수 있다 ClientRegistration clientRegistration = ClientRegistrations.fromIssuerLocation(“https://idp.example.com/issuer”).build(); 위 코드는 200 응답을 받을 때까지 https://i..

클라이언트 권한 부여 요청 시작 클라이언트가 인가서버로 권한 부여 요청을 하거나 토큰 요청을 할 경우 클라이언트 정보 및 엔드포인트 정보를 참조해서 전달한다 application.yml 환경설정 파일에 클라이언트 설정과 인가서버 엔드포인트 설정을 한다 초기화가 진행되면 application.yml 에 있는 클라이언트 및 엔드포인트 정보가 OAuth2 ClientProperties의 각 속성에 바인딩된다 OAuth2 ClientProperties에 바인딩되어 있는 속성의 값은 인가서버로 권한부여 요청을 하기 위한 ClientRegistration 클래스의 필드에 저장된다 OAuth2 Client는 ClientRegistration를 참조해서 권한부여 요청을 위한 매개변수를 구성하고 인가서버와 통신한다 ap..

deprecated 버전 client Support, Resource Server, Authorization Server 모두 하나의 프로젝트에 모듈로 포함되어 있었다. Spring Security 5 client Support, Resource Server는 Spring Security 5 프로젝트에, Authorization Server는 따로 분리되어있다. OAuth 2.0 Client Fundamentals OAuth 2.0 인가 프레임워크의 역할 중 인가서버 및 리소스 서버와의 통신을 담당하는 클라이언트의 기능을 필터 기반으로 구현한 모듈 간단한 설정만으로 OAuth 2.0 인증 및 리소스 접근 권한, 인가서버 엔드 포인트 통신 등의 구현이 가능하며 커스터마이징의 확장이 용이하다 OAuth 2...

ID Token ID 토큰은 사용자가 인증 되었음을 증명하는 결과물로서 OIDC 요청 시 access token 과 함께 클라이언트에게 전달되는 토큰이다 Access 토큰 자체는 인증이 되었다는 것을 증빙할 순 없지만, ID 토큰과 같이 전달이 되면 인증되었음을 증명할 수 있다. ID 토큰은 JWT(JSON 웹 토큰)으로 표현되며 헤더, 페이로드 및 서명으로 구성된다 ID 토큰은 개인 키로 발급자가 서명하는 것으로서 토큰의 출처를 보장하고 변조되지 않았음을 보장한다. 어플리케이션은 공개 키로 ID 토큰을 검증 및 유효성을 검사하고 만료여부 등 토큰의 클레임을 확인 한다 -> 인증 처리 클라이언트는 클레임 정보에 포함되어 있는 사용자명, 이메일을 활용하여 인증 관리를 할 수 있다 ID Token vs Ac..

OpenID Connect 1.0은 OAuth 2.0 프로토콜 위에 구축된 ID 계층으로 OAuth 2.0을 확장하여 인증 방식을 표준화 한 OAuth 2.0 기반의 인증 프로토콜이다 scope 지정 시 “openid”를 포함하면 OpenID Connect 사용이 가능하며 인증에 대한 정보는 ID 토큰 (ID Token )이라고 하는 JSON 웹 토큰(JWT)으로 반환된다 OpenID Connect는 클라이언트가 사용자 ID를 확인할 수 있게 하는 보안 토큰인 ID Token 제공한다 OAuth 2.0은 인증 처리를 하는 것이 목적이 아닌 인가 처리가 목적인 프레임워크이다. OpenId Connect 같은 경우 인증 프로토콜이다(User정보를 ID 토큰에 저장하며, 해당 토큰을 제공한다) OpenID C..

PKCE(Proof Key for Code Exchange, RFC - 6749) 개요 코드 교환을 위한 증명 키로서 CSRF 및 권한부여코드 삽입 공격을 방지하기 위한 Authorization Code Grant Flow의 확장버전이다. 권한부여코드 요청 시 Code Verifier와 Code Challenge를 추가하여 만약 Authorization Code Grant Flow에서 Authrozization Code 가 탈취당했을 때 Access Token을 발급하지 못하도록 차단한다. PKCE는 원래 모바일 앱에서 Authorization Code Grant Flow를 보호하도록 설계되었으며 나중에 단일 페이지 앱에서도 사용하도록 권장되으며 모든 유형의 OAuth2 클라이언트, 심지어 클라이언트 암..

흐름 및 특징 액세스 토큰이 발급될 때 함께 제공되는 토큰으로서 액세스 토큰이 만료되더라도 함께 발급받았던 리프레시 토큰이 유효하다면, 인증 과정을 처음부터 반복하지 않아도 액세스 토큰을 재발급받으실 수 있습니다. 한 번 사용된 리프레시 토큰은 폐기되거나 재사용 할 수 있다 권한 부여 승인 요청 시 매개변수 grant_type=refresh_token (필수) refresh_token client_id (필수) client_secret (필수) 동작 과정 TEST

흐름 및 특징 애플리케이션이 리소스 소유자인 동시에 클라이언트의 역할을 한다 리소스 소유자에게 권한 위임받아 리소스에 접근하는 것이 아니라 자기 자신이 애플리케이션을 사용할 목적으로 사용하는 것 서버 to 서버 간의 통신에서 사용할 수 있으며 IOT와 같은 장비 애플리케이션과의 통신을 위한 인증으로도 사용할 수 있다. Client Id와 Client Secret을 통해 액세스 토큰을 바로 발급받을 수 있기 때문에 Refresh Token을 제공하지 않는다 Client 정보를 기반으로 하기 때문에 사용자 정보를 제공하지 않는다. 권한 부여 승인 요청 시 매개변수 grant_type=client_credentials (필수) client_id (필수) client_secret (필수) scope (선택사항)..

흐름 및 특징 애플리케이션이 사용자 이름과 암호를 액세스 토큰으로 교환할 때 사용된다. 타사 애플리케이션이 이 권한을 사용하도록 허용해서는 안되고 고도의 신뢰할 자사 애플리케이션에서만 사용해야 한다. 권한 부여 승인 요청 시 매개변수 grant_type=password (필수) username (필수) password (필수) client_id (필수) client_secret (필수) scope (선택사항) 흐름 TEST

흐름 및 특징 클라이언트에서 Javascript 및 HTML 소스 코드를 다운로드한 후 브라우저는 서비스에 직접 API 요청을 한다 코드 교환 단계를 건너뛰고 대신 액세스 토큰이 쿼리 문자열 조각으로 클라이언트에 즉시 반환됩니다. 이 유형은 back channel 이 없으므로 refresh token 을 사용하지 못한다. 토큰 만료 시 어플리케이션이 새로운 access token을 얻으려면 다시 OAuth 승인 과정을 거쳐야 한다 권한 부여 승인 요청 시 매개변수 response_type=token (필수), id_token client_id (필수) redirect_uri (필수) scope (선택사항) state (선택사항) Access Token 요청 보안이 취약하므로 보안을 강화하기 위한 정책을 ..