Il termine viene da SAML; in OIDC lo stesso ruolo si chiama relying party o client. Lo SP manda gli utenti non autenticati all'IdP, riceve la risposta firmata, verifica firma, audience e finestra di validità e poi crea la propria sessione.
Per la configurazione lo SP ha bisogno dei metadati dell'IdP e pubblica i propri: entity ID, URL ACS e, se le richieste sono firmate, un certificato.
Molti errori lato SP dipendono dall'ambiente: dietro un reverse proxy lo SP genera URL sbagliati, oppure l'orologio di sistema è sfasato e asserzioni valide vengono scartate come scadute.