Identify the lawful basis before requesting data
Authenticating a user to provide your service is typically covered by the necessity of processing for a contract, but any additional scope you request from a provider, such as contacts or profile details, needs its own justification.
Ask only for the identity claim your login actually needs. Requesting broad scopes because a provider offers them creates data you must then justify, secure and eventually delete.
Minimize what passes through your systems
A narrow completion contract, such as provider name, status, tenant and email, is easier to justify and easier to secure than one that also carries profile photos, friend lists or access tokens your application does not use.
If a broker or identity layer already narrows the data on your behalf, resist the temptation to widen it again by logging full provider responses for debugging.
Set a real retention period for intermediate data
A login session record that exists only to bridge a provider redirect to your backend does not need to outlive that purpose. Short expiry, such as a ten-minute window, limits the retention question for that intermediate record almost entirely.
Your own longer-lived user record is a separate retention question, and it should have a documented period and deletion path tied to account closure or inactivity.
Handle deletion requests across two systems
When a user asks you to delete their data, remember that their provider account is unaffected and outside your control; you are responsible for what your application stored, not for the provider’s own records.
Make sure account deletion removes the mapping between your user record and the provider identity, not just profile fields, so a later login attempt cannot silently resurrect old data.
Be transparent about the providers you use
Name the specific login providers you support in your privacy notice, describe what you receive from them, and explain that the provider itself processes the authentication step under its own privacy terms.
If you operate across regions with different requirements, treat the stricter requirement as your baseline rather than maintaining divergent flows per region.