ID 및 접근 관리를 지원하는 인가서버 오픈 소스로 사용자 연합, 강력한 인증, 사용자 관리, 세분화된 권한 부여 등을 제공함
본 강의에 있어 OAuth2 Client와 Resource Server 커리큘럼에서 인가서버 플랫폼으로 사용함
Keycloak에 대한 자세한 내용은 공식 문서를 참고해서 공부할것(나는 지금 KeyClak 부분은 빠르게 넘어가야겠음)// 23년 1월 20일 내용 보충중
intelliJ Terminal에서 keycloak\bin 파일안으로 이동후 .\kc.bat start-dev
해당 명령어 입력 실행 성공시 8080포트로 실행됨(내 버전은 keycloak 20.0.1임)
(실행 실패시 java Home path잡을것 그래도 안될시 jdk 11 or 17 사용)
인가서버 및 리소스 서버와의 통신시 클라이언트 역할
-OAuth 2.0 메커니즘은 다음 네 가지 종류의 역활을 담당하는 주체들에 의해 이루어지는 권한 부여 체계이다.
Resource Owner (자원 소유자)
Resource Server (보호 자원 서버)
Authorization Server(인가 서버)
Client (클라이언트)
.\kc.bat start-dev
해당 명령어 입력해서 KeyCloak 실행
localhost:8080/
접속
왼쪽 탭에 master 클릭후 Create Realm
클릭이후 Realm name
에서 원하는 이름으로
해당 realm의 clients 탭에서 Create client해주면됨
Client ID & Name을 동일하게 설정(나는 test-oauth2-client로 만듬)
next클릭후 Capability config
항목에서 Client authentication = On으로 / Service accounts roles 체크하기
Settings에서 Valid redirect URIs설정(리다이렉트 uri를 설정하는것임
나는 강의와 같은 http://localhost:8081 사용)
아래 사진처럼 설정
Users -> Add user를 통해서 유저추가(다른건 원하는대로 설정하고 Enabled만 ON으로 생성후 Users
에서 해당 유저 클릭후 Credentials
항목에서 password 설정해줄것)
PostMan을 통해서 아래의 사진처럼 Get으로 uri & Key값 설정 value값은 설정한대로 하면됨
로그인 후 사용자의 권한 동의 페이지가 뜨는지 확인
위의 화면이 없을시 6번의 사진처럼 생성한 클라이언트 설정
로그인후 받은 코드를 이용해서 액세스 토큰을 받기 위해서 PostMan에 Post로 요청을 보내줌
client의 Credentials에서 Client secret 값 필요
getCode를 통해서 얻은 코드도 같이 보내주면됨(코드는 만료 기간이 존재해서 너무 오래된 코드라면 다시 로그인해서 얻어야함)
POST 방식을 이용하기 때문에 Body에 해당 내용을 담아줘야함
해당 문제는 처음에 로그인을 해서 code를 가져올때 openid
scope를 추가해주면 해결됨
이 페이지엔 추가해서 적어둠
개요
RFC 6749 - https://datatracker.ietf.org/doc/html/rfc6749#section-2.1
인증서버에 클라이언트를 등록할 때 클라이언트 자격 증명인 클라이언트 아이디와 클라이언트 암호를 받는다.
클라이언트 암호는 비밀이고 그대로 유지되어야 하는 반면 클라이언트 아이디는 공개이다.
이 자격 증명은 인증 서버에 대한 클라이언트 ID를 증명함
웹 앱
이라고 한다.
public client의 흐름
public client는 front channel에서만 인가 서버와의 상호 작용이 일어나며 서버측 과의 상호 작용은 일어나지 않음
client가 인가서버(Auth Server)에 권한 부여를 요청하며 바로 액세스 토큰을 발급해줌
하지만 confidential client에서 액세스 토큰발급은 최종적인 단계이며
프론트 채널에서 액세스 토큰을 발급하는 자체로도 탈취 당할 가능성이 생기기 때문에 현재는 deprecated됨
confidential client의 흐름
front channel & back channel 두 채널 모두와 상호작용이 일어남
먼저 front channel에선 client가 권한 부여를 요청시 인가 서버(Auth Server)는 토큰 대신 Code를 발급해줌
Back Channel에서 해당 Code를 가지고 다시 Auth Server에 가서 한번 더 해당 코드의 유효성 검사를 통과해야지 토큰을 발급해준다.
이때 Client Secret을 Code와 같이 전달하기 때문에 기밀성을 유지하며
사용자가 Client Secret을 알기 여려움
클라이언트 설정에서 Implicit flow(묵시적 흐름) 체크하고 저장해줌
Post 맨에서 url 수정 이후 브라우저에서 해당 url을 사용해서
인증 요청
발급 받은 토큰 확인
PostMan userInfo에서 토큰을 사용해서 사용자 정보 가져오기
앞에서 말했듯이 공개 클라이언트는 Client Secret을 사용할 수 없고 액세스 토큰을 바로 발급해주기 때문에 토큰 자체를 탈취하기 쉬워서 너무 큰 보안 취약점이 생기기 때문에
Deprecated된걸 느낄 수 있다.
사용자의 보호된 Resource에 접근하기 위해 사용하는 일종의 자격 증명
으로서 역활을 하며 Resource 소유자가 Client에게 부여한 권한 부여의 표현이다.인가서버는 데이터 저장소에 토큰의 내용을 저장하고 이 토큰에 대한 고유 식별자만 클라이언트에 다시 발행한다.
이 토큰을 수신하는 API는 토큰의 유효성을 검사하기 위해 인가서버에 대한 백채널 통신을 열고 DB를 조회한다.
JWT 토큰 형식으로 발급되며 클레임 및 만료가 있는 보호된 데이터 구조이다.
리소스 서버 API가 검증 키 등의 핵심 자료에 대해 알게 되며 발급자와 통신할 필요 없이 자체 포함된 토큰의 유효성을 검사할 수 있다.
특정한 암호화 알고리즘에 의해 개인키로 서명되고 공개키로 검증할 수 있으며 만료될 때까지 유효하다.
액세스 토큰이 만료된 후 새 액세스 토큰을 얻기 위해 클라이언트 응용 프로그램에서 사용하는 자격 증명
* ID 토큰은 OpenID Connect(OIDC) 사양을 준수하는 JSON 웹 토큰(JWT)입니다. 클레임이라는 키-값 쌍 집합으로 구성됩니다.
* 애플리케이션이 검사할 수 없는 불투명 객체인 액세스 토큰과 달리 ID 토큰은 애플리케이션에서 검사하고 사용하도록 되어 있습니다. 토큰에 서명한 사용자 또는 ID 토큰이 발급된 ID와 같은 토큰의 정보가 애플리케이션에서 사용하도록 제공됩니다.
* 자세한 설명은 다른 챕터에서
* `권한 부여 코드 흐름에서 사용되며 이 코드는 클라이언트가 액세스 토큰과 교환할 임시 코드이다.`
* 여기서 발급 받은 코드들은 1회용이며 사용후 폐기된다.
* 사용자가 클라이언트가 요청하는 정보를 확인하고 인가 서버로 부터 리다이텍트 되어 받아온다.
https://keycloak.discourse.group/t/issue-on-userinfo-endpoint-at-keycloak-20/18461/5