CODEWITHSUNDEEP
asp.net-coreopenidaspnet-contrib
Mark Dirksma
Mark Dirksma

Reputation: 23

openidconnect.server, third party providers & redirection

I'm currently building my an openid connect server using https://github.com/aspnet-contrib/AspNet.Security.OpenIdConnect.Server and asp.net core identity as a backing store. I'm aware of the protocols, the flows and the security holes.

The current setup is as follows: [server] - the authorization server & resource server [front-end] - an angularJS application [third-party-provider] - Google [external-app] - a second application which want to use a token from [server]

Both the [front-end] and the [external-app] are registered as clients for the [server]. So, they are allowed to retrieve tokens. The login page is build in the [front-end].

Keep in mind, that the login page etc is shown by the [front-end] application (instead of returning a AuthView from the AccountController)

Imagine i'd want to login with the [external-app] to get an identity from [server]. The login page is shown by [front-end]. Then the flow will be the following:

1. [external-app] -> http://[server]/account/authorize?client_id=[external-    
   app-clientid]&response_type=token&redirect_uri=http://[external-app- 
   redirecturi]
2. [front-end] -> matches route -> show login page
3. [front-end] -> user clicks on login with google
4. [front-end] -> redirect to 'http://[server]/account/authorize/connect?
   provider=Google&redirect_uri=http://[front-
   end]/account/thirdparty/authorized&response_type=code&client_id=[front- 
   end-clientid]
5. [server] -> no identity found, save request in session and let the user 
   login at the [third-party] (using ChallengeResult and also passing in the 
   request id which was stored in session)
6. [third-party-provider] user logs in
7. [front-end] -> http://[front-end]/account/thirdparty/authorized recieved 
   the code
8. [front-end] -> exchange authcode for token with [server] using 
   http://[server]/account/token&grant_type=authorization_code&code=
   [code]&redirect_uri=http://[front-
   end]/account/thirdparty/authorized&client=[front-end-clientid]
9. [server] -> generate claims and return token
10. [front-end] -> token recieved

A thing i'm missing (and it might be an implementation flaw, thought flaw or whatever) is that i need to redirect back to the [external-app] with the given token. Do i need to do that on the [front-end]? It feels off and i'm kinda sure i'm mixing / matching stuff wrong. Can anyone help me out?

Thanks in advance!

PS yes, i know, should be https. Above is for example purpose ;)

Upvotes: 2

Views: 372

Answers (1)

Kévin Chalet
Kévin Chalet

Reputation: 42100

With interactive flows like the implicit flow, the important thing to remember is that you have to redirect the user to the identity provider's authorization endpoint so it has a chance to prepare an authorization response.

You're free to decide what happens between the moment your identity provider receives the authorization request and the moment it returns an authorization response, but you can't redirect the user from your "front-end" application directly to the "external application" because it has no way to generate an authorization response (it's not its role).

Consider reworking your flow so your front-end app redirects your users to the authorization server, that will itself redirect them to your external app.

Upvotes: 0

Related Questions