What does it mean for two organisations to federate login between their identity providers, and what does each side stop doing?
answer
- two organisations, one sign-in
- somebody else runs the authentication
- accounts stay where the people are
- you verify, you do not authenticate
- a signed statement replaces a local password
basics
~20 sFederating login between organisations means each organisation's own identity provider authenticates its own people and vouches for them to the other's application. The application stops issuing credentials and storing passwords for those users, and instead validates a signed statement about them.
solid answer
~50 sIn login federation between two organisations, each side keeps the half it can actually run. The member organisation's identity provider holds the user records, runs the sign-in, and on request mints a signed statement saying that this person authenticated there, at that time, with these attributes. The relying application stops issuing credentials to those people, stops storing their passwords and stops running a joiners-and-leavers process for them; what it does instead is validate the signature against a key it already trusts, then map the asserted identity onto its own authorisation decision and its own local record. The trade is real: authentication strength, account lifecycle and revocation now happen inside an organisation you do not run or audit. Note this is federation between organisations' identity providers, not workload-identity federation between a build system and a cloud account.
go deeper
Recall the two roles and the direction: the user's own organisation authenticates and vouches, your application verifies and admits. Name one thing your side stops doing — storing passwords for those users is the clearest.
Explain the split precisely: credential and authentication strength sit with the identity provider, entitlements and session lifetime stay with the relying application, and the signed statement is the only thing that crosses.
Show the operational consequence you have lived with: the revocation gap between a leaver being disabled and their live session ending, and how you sized local session lifetime against it.
Frame it as a dependency you accept on another organisation's security operations: their authentication strength, their off-boarding discipline and their incident become inputs to your risk, and the contract, not the protocol, is where you set expectations.
## What the word means here **Federation**, in this branch, means login crossing an organisational boundary: your application accepts an authenticated identity that was established by an **identity provider** somebody else operates. The word is overloaded — it is also used for a build pipeline trading a token for cloud credentials, for a stitched-together query graph, and for data catalogues — so the first thing to say in an interview is which one you mean. Here it is people signing in across organisations. The arrangement has two roles. The **identity provider** belongs to the organisation the person actually works for: it holds their record, decides how they prove who they are, and is the only party that ever sees their credential. The **relying party** — called a service provider in the older XML standard — is the application being entered. It never authenticates the user. It receives a signed statement about the user and decides whether to believe it. ## What each side stops doing The relying application stops doing four things for those users: - **Issuing credentials.** No account creation, no invitation email carrying a password, no password reset path for a person whose employer already has one. - **Storing password material.** There is nothing to hash, nothing to rotate and nothing to leak for that population. - **Running the joiners-and-leavers process.** Hiring and termination happen where employment happens. - **Deciding authentication strength.** Whether a second factor was used, and how strong it was, is decided at the identity provider. The member organisation stops doing one large thing: maintaining a parallel set of accounts in every counterparty's system, each with its own password and its own forgotten off-boarding. ## What nobody stops doing This is where candidates overclaim. Federating login does **not** remove: 1. **The local record.** Your application still needs a row for the user — their entitlements, their history, their audit trail — keyed to a stable identifier from the assertion rather than to an email address someone may change. 2. **Authorisation.** Who the person is and what they may do are separate decisions. The remote statement answers the first; your own rules answer the second. 3. **Session lifetime.** Once your application has started a local session, it is yours. It does not consult the identity provider again on every request unless you build that. | Concern | Owned by the identity provider | Owned by the relying application | |---|---|---| | Credential and sign-in | Yes | No | | Authentication strength | Yes | Accepts or refuses it | | Joiners and leavers | Yes | Reacts to it | | Entitlements in the application | No | Yes | | Local session lifetime | No | Yes | | Audit of what was done | No | Yes | ## What you are actually accepting Accepting a federated login is accepting an assertion you did not make, signed by a key you chose to trust, about an account whose lifecycle you cannot see. Three consequences follow, and a good junior answer names at least one: - **Revocation is not instant.** A leaver is disabled at their identity provider immediately, but a live session in your application continues until it expires or you end it. The gap is however long your session lasts. - **Attribute quality is theirs.** If the assertion says someone is a compliance officer, that is their word for it. Your authorisation rules inherit their data hygiene. - **Their incident is your incident.** If their identity provider is compromised, valid assertions about anyone arrive at your door and every signature checks out. ## Why the shape is worth learning before any standard Every federation standard — the XML-era browser SSO family, the JSON and token-era one, and the third that estates still carry — implements the same shape: an authority mints a signed statement, a relying party validates it and maps it locally. The standards differ in the credential format, in what a client must be able to do to take part, and in what they can express about logout and attributes. Learn the shape first and the standards become variations rather than three unrelated subjects. A compact way to say all of this in an interview: *we stopped being an account authority for those users and became a verifier of somebody else's claim about them, and we kept every decision about what they may do here.*
- The member organisation disables an employee at its identity provider. When does your application actually stop serving that person?Not necessarily at once. New logins fail immediately, because the identity provider will no longer authenticate them. An existing session in your application runs until that session expires or something ends it, since your application is not re-asking the identity provider on every request. If the gap matters, you shorten local sessions or subscribe to whatever the chosen standard offers for notifying a relying party, and you accept that the standards differ on what that is.
- What must your application still decide for itself after a federated login succeeds?Everything about authorisation and local state: which entitlements this person has here, whether a first-time arrival is provisioned a record at all, which stable identifier that record is keyed to, and how long the local session lives. The assertion answers who authenticated and how; it does not grant anything in your system.
- Is single sign-on between two of your own internal applications the same thing?No. Sharing one sign-in across applications inside one organisation is single sign-on with one authority you operate. Federation is specifically the case where the authority sits in another organisation, which is what makes trust establishment, standard selection and assurance into real questions rather than configuration.
A conference badge printed by your own employer that the venue's door staff inspect and accept, rather than phoning your employer about each attendee. The venue still decides which rooms the badge opens, and a badge already inside the building keeps working after the employer revokes it.
saying these in an interview costs you the question
- Says federation means copying the partner's user accounts into your own database
- Thinks a federated login removes the need for local authorisation decisions
- Assumes disabling a user at the identity provider instantly kills their live session in your application
- Confuses it with a build pipeline federating into a cloud account
- Believes the relying application ever sees the user's password
- Treats the asserted attributes as verified facts rather than the partner's word