Okta (OIDC) 설정
OpenID Connect를 사용하여 Okta로 통합 로그인을 구성하는 단계별 가이드입니다.
사전 요구 사항
- Okta 관리자 계정
- SecureCodingHub 조직 관리자 계정
1단계 — Okta 애플리케이션 생성
Okta Admin Console → Applications → Create App Integration으로 이동
로그인 방법: OIDC
애플리케이션 유형: Web Application
앱 이름: SecureCodingHub
로그인 리다이렉트 URI: https://api.limeplate.com/api/sch/auth/sso/callback/oidc
할당: 사용자/그룹에 할당
2단계 — 자격 증명 복사
Okta 애플리케이션에서 다음 값을 수집하세요:
| 설정 | 찾을 위치 |
|---|---|
| Client ID | General → Client Credentials |
| Client Secret | General → Client Credentials |
| Okta 도메인 | Okta URL (예: dev-12345.okta.com) |
| Discovery URL | https://{okta-domain}/.well-known/openid-configuration |
3단계 — SecureCodingHub에서 SSO 구성
조직 관리자로 로그인 → SSO 설정
프로토콜: OIDC
Entity ID / Client ID: Okta Client ID 붙여넣기
Discovery / Metadata URL: Okta OpenID 구성 URL 붙여넣기
Client Secret: 시크릿 붙여넣기
SSO 활성화
저장 클릭
4단계 — 테스트
익명/비공개 브라우저 창 열기
SecureCodingHub 로그인으로 이동
조직의 도메인이 있는 이메일 주소 입력
Okta 로그인으로 리다이렉트되어야 함
인증 후 SecureCodingHub에 로그인되어야 함
일반적인 Okta SAML 함정
이 가이드는 OIDC에 중점을 두지만, 많은 Okta 테넌트가 SAML을 통해 SecureCodingHub를 실행하며 동일한 Okta별 문제가 반복됩니다. 첫 번째는 audience URI 불일치입니다. Okta는 SAML General Settings에서 이 필드를 Audience URI (SP Entity ID)라고 부르며, 값은 SecureCodingHub가 엔티티 ID로 게시하는 것과 정확히 일치해야 합니다. 일반적인 실수는 API 엔티티 ID가 아닌 SecureCodingHub 웹사이트 URL을 입력하는 것입니다. Okta 애플리케이션을 저장하기 전에 SecureCodingHub SSO 설정 페이지의 SP Entity ID 필드에 대해 값을 확인하세요.
두 번째 함정은 Okta 앱 로그인 정책입니다. Okta는 추가 요소를 요구하거나, 네트워크 영역으로 제한하거나, 그룹 멤버십을 기반으로 액세스를 완전히 거부할 수 있는 애플리케이션 수준 정책을 적용합니다. 최종 사용자가 SSO가 그들을 Okta로 리다이렉트한 다음 액세스 거부 오류로 다시 튀어 오른다고 보고하는 경우, 원인은 거의 항상 테스트 사용자와 일치하지 않는 앱 로그인 정책 규칙입니다. 애플리케이션 아래의 Sign On Policy를 확인하고 테스트 사용자에게 적용되는 규칙을 확인하세요. 세 번째 일반적인 함정은 일치하지 않는 Name ID 형식입니다. Okta는 Unspecified로 기본 설정되지만, SecureCodingHub는 emailAddress 형식을 예상합니다. 애플리케이션 설정에서 Name ID 형식을 EmailAddress로 설정하고 소스 속성이 user.email 또는 user.login인지 확인하세요.
SSO가 종단 간 작동하는지 확인하는 방법
확인은 이전 로그인의 모든 쿠키를 피하기 위해 익명 브라우저 세션에서 시작됩니다. SecureCodingHub 로그인 페이지로 이동하고, 검증된 도메인의 기업 이메일 주소를 입력하고, 브라우저가 Okta 테넌트로 리다이렉트하는지 확인합니다. Okta에서 인증한 후, 리다이렉트는 올바른 조직의 대시보드의 SecureCodingHub로 도착해야 합니다. 일반 랜딩 페이지 또는 404에 도착하면, 가장 가능성 있는 원인은 사용자가 아직 SecureCodingHub에 존재하지 않고 JIT 프로비저닝이 비활성화되거나 생성 이벤트를 거부했다는 것입니다.
둘째, 역할 및 좌석 할당을 확인하세요. JIT 프로비저닝된 사용자는 항상 learner 역할로 도착합니다 — SecureCodingHub는 오늘 Okta 그룹 클레임에서 역할 정보를 읽지 않으므로, org_admin로의 승격은 사용자가 존재한 후 SecureCodingHub 관리자 UI에서 수행해야 합니다. 셋째, 로그아웃한 다음 다시 로그인하세요. 두 번째 로그인은 Okta 세션 쿠키 덕분에 거의 조용해야 합니다. 두 번째 로그인이 전체 재인증을 강제하는 경우, Okta 세션 수명이 정상 사용에 너무 짧게 설정되어 있습니다. 전역 세션 정책 또는 애플리케이션 로그인 정책을 그에 따라 조정하세요. 프로토콜 수준 세부 정보는 SAML 설정 가이드를 참조하세요.