You can demonstrate single sign-on without touching an employer's production application. Use a supported test application, a compatible identity provider, and fictional users.
Your project should answer two questions: can you explain the working sign-in flow, and can you diagnose one controlled failure?
Start with a documented configuration and establish a successful baseline. The value comes from explaining the integration and its evidence, not merely showing that two products are running in your home lab.
Choose a supported sample that fits your environment
Use a sample application intended for the protocol supported by your chosen identity provider.
Keycloak's application-integration guidance, for example, covers registering a client and integrating compatible applications using OpenID Connect or SAML.
Before starting, check:
- Compatibility: Does the example match the protocol and product version you're using?
- Prerequisites: Can your lab meet its documented requirements?
- Scope: Does it demonstrate the integration you want to explain?
- Isolation: Are the identities, data, and resources strictly for testing?
Follow the supported configuration rather than combining unrelated steps from old tutorials.
A development example may deliberately simplify deployment concerns. Keep those limitations visible and don't describe the resulting lab as a production-ready architecture. The objective is a controlled, understandable sign-in integration that you can test safely.
Write down the integration contract
Before testing, record the non-secret settings that must agree between the application and identity provider.
Depending on the protocol and application, these may include the client or entity identifier, expected issuer, callback or reply address, and the information used to identify the user.
Keep secrets outside public documentation. Do not publish client secrets, private keys, live tokens, or session captures to make the project look technical.
Your public diagram should explain the relationship while leaving sensitive implementation material out.
Establish a successful baseline first
Sign in with a fictional test user and confirm the intended application behavior.
Record what happened at each stage: the application initiated sign-in, the identity provider handled authentication, and the application accepted the result for the expected user.
Do not assume a successful identity-provider login proves the application works. Verify the actual outcome in the application.
Save enough sanitized evidence to compare against a later failure. Without a baseline, you may spend the project investigating several unrelated setup problems at once.
Introduce one reversible configuration error
Choose a documented setting whose role you understand, such as a callback-address mismatch in a suitable OIDC test.
Record the original value privately, change only that setting, and observe the failure. Then restore it and repeat the test.
The aim is to identify where the systems disagreed and which evidence supported the diagnosis. Do not disable validation, use broad wildcard settings, or weaken security checks merely to make the error disappear.
The controlled SSO misconfiguration exercise can help you frame the experiment as troubleshooting rather than random breakage.
Separate sign-in from authorization
After the integration works, ask what the application allows the user to do.
A basic sample may demonstrate authentication without a meaningful role model. State that limitation. Do not describe it as proof of fine-grained authorization unless you actually configured and tested those controls.
You can add a separate access test later when the application supports it and the target role makes it relevant.
Keeping the first claim narrow makes the evidence easier to defend.
Publish the explanation, not the session contents
Your project page should contain a simple flow diagram, the important configuration relationships, the successful baseline, the controlled failure, and the verified recovery.
Describe what you learned and what remains outside scope. Include links to the official documentation you followed so someone can understand the implementation context.
Use a sanitized screenshot only when it supports a specific claim. Raw authentication traces can contain material that should never be published.
The Six-Figure IAM Career Playbook places SSO alongside directory access and identity lifecycle work in a practical career plan. The $9 guide helps you select a project for the role you want. A supported sample application is enough to begin building evidence you can explain honestly.