API authenticeren met 3rd party OAuth provider?

[Carharttguy]

Beste

Ik ben bezig met een vrij typische applicatie die bestaat uit een API en een frontend.
Authenticatie met mijn eigen backend is simpel, je stuurt een gebruikersnaam/wachtwoord door naar de login endpoint en krijgt een bearer token en refresh token om respectievelijk afzonderlijke requests te doen en na 30 minuten of een uur een nieuwe bearer token aan te vragen.

Maar nu kom ik bij de eigenlijke vraag: Wat met 3rd party OAuth providers? Ik zou graag hebben dat klanten kunnen inloggen met hun Google credentials. Ik heb een oplossing hoe het zou kunnen werken:

Frontend heeft knopje 'Login with Google', na het authenticeren met Google krijgt mijn frontend via een callback een access token van Google.
Frontend stuurt de access token van Google door naar API.
API fetched de userinfo van Google en kijkt of het emailadres overeenkomt met een gebruiker in mijn systeem.
API geeft een bearer en refresh token uit (net zoals in de eerste paragraaf)

Is dat de manier om het te doen? Of moet ik als callback (redirect URL) naar Google onmiddellijk naar mijn API verwijzen? Dat lijkt veiliger, maar dan lijkt het me moeilijker om een bearer en refresh token naar de frontend te sturen (aangezien er geen request is vanuit de frontend naar API)

Bedankt voor alle opmerkingen, wijze raden en andere nuttige inbreng!

[_360_]

In mijn laatste opdracht had ik dezelfde situatie dat ik voor onze applicatie eigen JWT tokens wilde uitgeven op basis van een 3rd party OAuth authorization provider.

In die situatie heb ik voor de 2e optie gekozen.

Je kan de redirect url voor google naar een REST endpoint in je eigen applicatie laten wijzen.
Vervolgens moet je weten om welke client het gaat. Binnen OAuth mag je naast de redirect url een state parameter meegeven. Dit is een base64 encoded key die je zelf kan bepalen.
Deze state parameter wordt terug gepost door google bij de redirect url.

Omdat we .NET Core gebruikten in ons project kon ik met SignalR een PubSub Hub maken die een token naar de client kon sturen nadat de redirect van de 3rd party provider terug kwam. In een andere stack kan je met WebSockets hetzelfde bereiken.

In stappen ziet dat er zo uit:

1. User klikt op 'Aanmelden met google'
2a. FrontEnd called RegisterClient middels SignalR
2b. SignalR registreert de Client en returned een Guid
2c. FrontEnd redirect naar google, met redirectUri naar eigen api en base64 encoded Guid als State parameter
3. User authenticate middels google.
4. Google doet GET request naar API endpoint inclusief state parameter.
5. Api genereert Bearer token.
6. Api pushed token middels SignalR naar client die registered is onder de (decoded state parameter) Guid.
7. Frontend ontvangt bearer token.
8. Profit.

[Hydra]

OAuth is meestal een 2-traps raket. Een gebruiker komt op een page en daarna kom je via een redirect op je front-end uit en staat een tijdelijk token in de GET, meestal als query param. Die tijdelijke token stuurt je front-end naar je back-end, en die gaat dan met dat tijdelijke token de access token ophalen. De front-end heeft dus nooit dat access token in handen. De back-end kan dat access token zolang het nodig heeft (en het geldig blijft) gebruiken om de data van de gebruiker te accessen. Die kan dan ook aan de hand van de info de gebruiker inloggen (of een nieuwe gebruiker maken als het mailadres niet bekend is) en de bearer token naar de client sturen.

Dus: Front-end > Google login -> Redirect naar je front-end -> Front end called back-end -> Back-end logt in met credentials.

Die callback gaat dus nooit rechtstreeks naar je API, want het is een pagina waar de user naartoe geredirect wordt.

[DJMaze]

Carharttguy schreef op dinsdag 17 september 2019 @ 09:42:
Ik zou graag hebben dat klanten kunnen inloggen met hun Google credentials.

Inloggen is niet het zelfde als OAuth.
OAuth is voor authorization en niet voor authentication.

Maar... dat verschil is tegenwoordig vervaagd omdat we OpenID Connect hebben.
Je maakt dus een app aan in Google/Etc. die alleen bedoelt is voor inloggen.
Je hoeft dan geen OAuth tokens te bewaren en je hebt geen toegang tot google apps.
Je gebruikt de token alleen voor het ophalen van gebruiker info.

[Carharttguy]

_360_ schreef op dinsdag 17 september 2019 @ 11:29:
In stappen ziet dat er zo uit:

1. User klikt op 'Aanmelden met google'
2a. FrontEnd called RegisterClient middels SignalR
2b. SignalR registreert de Client en returned een Guid
2c. FrontEnd redirect naar google, met redirectUri naar eigen api en base64 encoded Guid als State parameter
3. User authenticate middels google.
4. Google doet GET request naar API endpoint inclusief state parameter.
5. Api genereert Bearer token.
6. Api pushed token middels SignalR naar client die registered is onder de (decoded state parameter) Guid.
7. Frontend ontvangt bearer token.
8. Profit.

Dit was ongeveer mijn tweede denkpiste inderdaad, echter wil ik in deze applicatie liever stateless blijven, en niet mer Websockets of derivaten daarvan aan het werk. Goede tip echter!

Hydra schreef op dinsdag 17 september 2019 @ 13:22:
Dus: Front-end > Google login -> Redirect naar je front-end -> Front end called back-end -> Back-end logt in met credentials.

Die callback gaat dus nooit rechtstreeks naar je API, want het is een pagina waar de user naartoe geredirect wordt.

Dit is inderdaad wat ik initieel in gedachten had. Blij dat ik toch op de juiste denkpiste zat.

DJMaze schreef op dinsdag 17 september 2019 @ 13:50:
[...]

Inloggen is niet het zelfde als OAuth.
OAuth is voor authorization en niet voor authentication.

Maar... dat verschil is tegenwoordig vervaagd omdat we OpenID Connect hebben.
Je maakt dus een app aan in Google/Facebook/Etc. die alleen bedoelt is voor inloggen.
Je hoeft dan geen OAuth tokens te bewaren en je hebt geen toegang tot google apps.
Je gebruikt de token alleen voor het ophalen van gebruiker info.

Interessant, dat wist ik niet. Ga dat OpenID Connect eens bekijken. Hoewel er ook OAuth Providers zijn die die oplossing niet hebben (Google was slechts een voorbeeld in mijn verhaal, er zijn nog enkele kleinere OAuth providers betrokken)

Thanks voor de OpenID tip.

[ Voor 25% gewijzigd door Carharttguy op 17-09-2019 14:35 ]

[Janoz]

Carharttguy schreef op dinsdag 17 september 2019 @ 14:33:
Dit was ongeveer mijn tweede denkpiste inderdaad, echter wil ik in deze applicatie liever stateless blijven, en niet mer Websockets of derivaten daarvan aan het werk. Goede tip echter!

In dat hele stappenplan zie ik nergens iets met websockets, en alles kan nog steeds keurig stateless blijven? Waarom denk je dat dat niet zo is?

[Carharttguy]

Janoz schreef op woensdag 18 september 2019 @ 09:48:
[...]

In dat hele stappenplan zie ik nergens iets met websockets, en alles kan nog steeds keurig stateless blijven? Waarom denk je dat dat niet zo is?

SignalR is toch gebouwd op Websockets? Ik zie anders niet hoe een client data zou kunnen ontvangen van een server zonder dat er een request geinitieerd is vanaf de client naar die server.

Zo dacht ik het althans, ik ben niet zo thuis in die zaken.

[ Voor 7% gewijzigd door Carharttguy op 18-09-2019 10:44 ]

[Janoz]

Ik ken SignalR ook niet, maar 2a lijkt me het request en 2b lijkt me het response. Daar is niks 'websocketerigs' aan.

[Carharttguy]

Ik had het over stap 6. Api pushed token middels SignalR naar client die registered is onder de (decoded state parameter) Guid.

Pushen lijkt mij 'websocketeterigs'.

[Janoz]

Ah ok. Dat werkt niet zoals je nu denkt. Google doet niet een request naar je backend. Google doet een redirect. Je client gaat dus naar je backend, samen met het door google gegenereerde state parameter. Jouw backend doet vervolgens een request bij google met state en guid en kan de informatie ophalen die nodig is. Je backend genereerd het bearer-token, of wat je ook maar wilt gebruiken voor je inlog, en geeft dit als response terug aan je frontend.