code in readme.md cause cyclical redirct

[John0King]

If you don't want to display a login form that tells the user that they are redirected to the identity
server, you can use the convenience function this.oauthService.loadDiscoveryDocumentAndLogin(); instead of this.oauthService.loadDiscoveryDocumentAndTryLogin(); when setting up the library.

This directly redirects the user to the identity server if there are no valid tokens.

after use this.oauthService.loadDiscoveryDocumentAndLogin() , the app into an infinity redirct circulation

[jeroenheijmans]

The loadDiscoveryDocumentAndLogin method does two things:

1. loadDiscoDoc...: call the well-known endpoint at the identity server for the discovery document; after that promise resolves it goes to...
2. ...AndLogin: which immediately redirects you to the login endpoint of your identity server

So if you always call that method at the start of your application, then you'd indeed keep getting sent back to the IDS.

I've not found much use for that specific method. I guess you could do this:

// check if you got redirected and an access token was passed along first:
this.oauthService.tryLogin().then(() => { 
  if (this.oauthService.hasValidAccessToken()) {
    this.oauthService.loadDiscoveryDocument();
  } else {
   this.oauthService.loadDiscoveryDocumentAndLogin();
  }
});

But I tend to do things more explicitly, along these lines:

https://github.com/jeroenheijmans/sample-angular-oauth2-oidc-with-auth-guards/blob/e536a89d4e9e4dc2366ba7c594d79ca54bca07ca/src/app/core/auth.service.ts#L88-L157

[John0King]

when use openid for a server side app, normally the server side app has a callback path for handle openid signin, and another path for handle signout , and those two path will redirect to the path belong to the app, for example /.

this is how openid work in an asp.net core app: note: ~/ meaning it is the root path of the current app (if the current root path is / it will be / , if it's /api , then it will be /api)

`~/admin`  -- secure path
----> AuthorizationFilter ---> if not login ---
--> (capture current path to a querystring called `ReturnUrl`  of   the  `ReturnUrl`  and  
then `challenge` to OIDC authorize endpoint  )  `https://auth.com/?returnurl=http://myapp.com/login-oidc?returnurl=/admin`
---<>> after oidc login call back 

--> `~/login-oidc`  -- now in this path, it  can process the accesstoken to claims , and 
get the `returnUrl` query string, which is `/admin` in this case,   and redirct to `/admin`  
(because it's a server side app, it will write a cookie to save the claims)

--> `~/admin`  -- now AuthorizationFilter  check is pass  and show the page

so I think the best match to the asp.net core, is route guard in Angualr,
and register a new route to the angular app called spa-callback-oidc by default , and handle sign in here, and more importantly, the guard is support Promise

[jeroenheijmans]

I'm not sure what you're exactly asking or telling us? If you need more help, or think you've found a bug, could you please provide a way to reproduce?

(Specifically, I'm unclear why you compare with server side apps, this lib is primarily used in Single Page Applications. What flow are you using, implicit ir code?)

[John0King]

I'm unclear why you compare with server side apps

The reason I compare with service side app (asp.net core ) is because in asp.net core it difine a very easy to use and flexiable way to use the OIDC protocal , I'm hoping that can be implement in this library too.

I'll contribute to this library when I get free time.

[jonyeezs]

I noticed that it'll send a request to the identity server and redirect back to the app with a hash param of the id tokens but looks like it never gets registered/loaded/consume before it hits the bootstrapped component. Is there something missing here?

[jeroenheijmans]

tryLogin is the method that would grab the token (implicit flow) from the hash fragment, clear the hash, and then continue parsing/storing the result. Call that explicitly, or call an method that ends with it (e.g. loadDiscoveryDocumentAndTryLogin().

I've not found the loadDiscoveryDocumentAndLogin() method to be useful in any application myself. I think you'll always want to check the hash fragment after loading the disco document and before redirecting people to login.

I recommend being explicit, not using one of the blah And blah And blah() methods, but instead just specifying the chain of login checks explicitly yourself. There's an annotated version of my approach in my sample repository.

[jonyeezs]

@jeroenheijmans is right.

I think what threw us off was the method name "...Login()". We assumed it was checking to see if we were authenticated, if not send us to the login page.

But all it did was to check if the request had the correct hash fragments to obtain the access key.

Steps we took that works:

1. use loadDiscoveryDocumentAndLogin for the page that would be redirected from the login screen as well as loading the app.
2. Use the boolean result of the above method to begin init initImplicitFlow to send user to login page otherwise begin the app.

[jeroenheijmans]

Good to hear you've found a solution. Shall we close this one then? Or will you suggest a PR with a change to readme to clarify things further? Either's good to me.

[jonyeezs]

Would love to put a PR in. And get that for hacktoberfest heh

…

On Tue, 8 Oct 2019, 12:38 am Jeroen Heijmans, ***@***.***> wrote: Good to hear you've found a solution. Shall we close this one then? Or will you suggest a PR with a change to readme to clarify things further? Either's good to me. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#639?email_source=notifications&email_token=ACS4BBS7GNQMJESAR4Y3ON3QNNCWHA5CNFSM4I3C6BR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAQSPOA#issuecomment-539043768>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACS4BBVF2K7VIMGSVAQCT2TQNNCWHANCNFSM4I3C6BRQ> .