실제 인증 처리 과정

• 인증을 처리 인가서버 통신을 해서
• RequestEntity 변경 Rest로 통신을 위해

• 헤더명 인가 실제 엑세스 토큰을 Bearer 타입으로 토큰을 포함해 보낸다

• 응답으로 바디에 sub , email등 사용자의 속성을 가지고 온다.

• 그리고 변환해서 DefaultOAuth2User로 변환

• 그리고 OAuth2LoginAuthenticationToken 객체를 만들어서 저장을 한다.

• OAuth2AuthenticationToken 을 완성한다.

• principal에 저장 되서 이 객체는 SecurityContext안에 저장 됨

• OAuth2AuthorizedClinet 그리고 이 과정에서 이객체를 만듬

• 클라이언트를 액세스토큰에 견결 함. 권한부여를 받은 클라이언트다.

• 나중에 별도에 값으로 참조할 수있음

• 실제로 인증 객체를 제공함, 인증받은 사용자의 정보를 제공 함

• OAuth2AuthorizedClinet 사용자와 인증을 받게끔 토큰 값을 제공,

• OAuth2AuthorizedClinet / OAuth2AuthenticationToken mvc 서블릿 환경 참조해서 기능을 구현가능함

OpenID Connect Provider Userinfo endPoint 요청

• 인가서버로 부터 코드 발급 엑세스토큰 발급 받는 과정을 진행함
• OidAuthorizationCodeAuthenticationProvider
• AuthenticationProvider -> 실제 인증처리 클래스
• oicd 방식요청하면 additionalParameters에 담김 idToken이
• idToken으로 인증받는다? -> 인가서버에서 이미 서명을 마침 (idToken) 개인키로 서명 되있음
• 실제로 인증처리를 위해서 인가서버에서 발급받은 토큰이 맞는지 공개키로 검증을 해야 됨!
• OIDC 조건에 포함되지 않으면 바로 인증처리
• 아니면 RequestEntity로 인가서버랑 통신하는 요청객체 만들어서 인가서버 통신

통신하는 과정은?

• 둘다 약간의 차이가 있지만 방식은 비슷하다

코드 디버깅

• 키클록의 기본 유저네임을 검색할 수 있는 속성의 이름 preferred_username

• 토큰을 받아오는 단계 그 다음 인증은?
• authoenticationManager에게 위임을하고

• openid가 포함되있나?

• 인증 처리하는 구현체

• 상태값 비교를 하고

• 레스트로 인가 서버통신하고

• 토큰을 발급받는다

• 엑세스토큰 으로 인증처리

• 컨버트를 하고

• 인가서버 통신 사용자정보가져옴

• 사용자 정보를 가져옴 인증처리를 하기위한

• 권한 매핑

• 권한 매핑 완료

• 여기까지하면 DefaultUser 를 반환하면 인증이 완료 된것이다.
• 실질적으로 인증객체토큰을 생성하기 위한 구성하는 곳

• 해당 유저는 엑세스토큰의 권한을 가진다.

• 인증 성공
• OAuth2.0 provider 기본 인증 처리 방식

openIdConnect 인증방식

• openId 포함해서 옴

• 토큰 발급받는중 ..

• id_token 별도로 생성 되었음

• 서명이 되어있는 idToken

• 유저정보들

• 디코더에서 IdToken 검증
• 일단 디코더를 만드는 중

• 어떤 값을 검증하느냐? jwt 토큰을 검증 한다.

• 검증이 끝나면 claim정보가 들어온다.
• 그리고 OidcToken 만들고 이걸로 검증처리를한다.

• 검증을 끝내고

• 인증을 진행

• 인증서버로가서 추가적인 claim 정보를 가져옴

• 사용자정보를 다시 인가서버에서 가져와야되는가? 더?

• 유저 리퀘스트 안에 있는 토큰 안에있는 스코프가 만약 엑세서블 안 스코프에 포함되있냐 검증

• openin만 주고 암것도 안줘서 통과안하는 줄알앗는대 profile? 왜생긴건지 모르겠지만 참이라
• 인가서버로 다녀옴

• 다시 했을 때 캐시에남아있는 값이없이 깨긋하게 오픈아이디만 남음

• 권한 만드는 중
  

• 유저 가져오는 중

• 어트리뷰트스에는 유저네임을 가져올수 있는 키가 있어야된다.

• 안그러면 오류 내 뱉음.

• sub으로 바꾸면 ?

• 오류가 나지않고 사용 sub 값이 있으니?

• 실제 클라이언트가 권한정보를 받았어!

• 마지막으로 시큐리티 컨텍스트안에 저장

• 스코프에 포함되는 값이 있어서 참이다.

• 즉 Profile 정보를 추가했는대 인가서버에서 제공 하고 있어서
• preferred_username이 있깅 오류 안뱉음

• idToken가지고 인증 처리를 하지만 추가적인 claim을 가져와야되거나 필터링 별도로 구성해야될때
• 인가서버로가서 필요한 클레임 정보를 가져온다 (인증목적이아니라)