1

I'm trying to use the library angular-oauth2-oidc in my application.

This is my AuthConfig

const adsfUrl = 'https://xxxx.xxxxx.xxx/adfs';

export const ADSF_AUTH_CONFIG: AuthConfig = {
    redirectUri: window.location.origin,
    clientId: 'debdb149-65c3-4ac7-99c5-acbfa59f66d0',
    requireHttps: false,
    loginUrl: adsfUrl + '/oauth2/authorize',
    issuer: adsfUrl,
    scope: 'openid profile email',
    responseType: 'id_token token',
    oidc: true,
    logoutUrl: adsfUrl +
      '/ls/?wa=wsignoutcleanup1.0&wreply=' + location.protocol +
      '//' + location.hostname + (location.port ? ':' + location.port : ''),
    postLogoutRedirectUri: location.protocol + '//' +
      location.hostname + (location.port ? ':' + location.port : '')
};

This is the component where I configure my solution for the implicit flow:

 export class UnauthorizedHomePageComponent implements OnInit {
  returnUrl: string;
  constructor(
    private oauthService: OAuthService,
    private router: Router,
    private activatedRoute: ActivatedRoute
  ) {}

  ngOnInit(): void {
    this.oauthService.configure(ADSF_AUTH_CONFIG);

    this.oauthService.tokenValidationHandler = new JwksValidationHandler();

    if (!this.oauthService.hasValidAccessToken()) {
      this.oauthService.loadDiscoveryDocumentAndTryLogin().then(() => {
        if (this.oauthService.hasValidAccessToken()) {
          const obj = {
            identity: this.oauthService.getIdentityClaims(),
            token: this.oauthService.getAccessToken(),
            idtoken: this.oauthService.getIdToken(),
          };
          console.log(obj);
          this.router.navigate(['pages']);
        }
      });
    }
  }
}

As you can see I don't call the this.oauthService.initImplicitFlow() in the code above. I do that in a child component where I also collect a couple of additional details of the user and store them to localstorage before redirecting them to the identify provider.

This code works kinda fine. I say kinda because even though the user is redirected to the identity provider and also correctly identified, the token is nowhere to be seen neither in Local Store or Session Storage, even though I can see the token been returned in the url :

http://localhost:4200/#access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5zaUk3eXBnU2dPOFc0SXYtWWdYQk5OMzZHbyJ9.eyJhdWQiOiJtaWNyb3NvZnQ6aWRlbnRpdHlzZXJ2ZXI6ZGViZGIxNDktNjVjMy00YWM3LTk5YzUtYWNiZmE1OWY2NmQwIiwiaXNzIjoiaHR0cDovL2FkZnNxYS5iZWxjb3JwLmJpei9hZGZzL3NlcnZpY2VzL3RydXN0IiwiaWF0IjoxNTkzMTMxNjI3LCJleHAiOjE1OTMxMzUyMjcsImFwcHR5cGUiOiJQdWJsaWMiLCJhcHBpZCI6ImRlYmRiMTQ5LTY1YzMtNGFjNy05OWM1LWFjYmZhNTlmNjZkMCIsImF1dGhtZXRob2QiOiJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YWM6Y2xhc3NlczpQYXNzd29yZFByb3RlY3RlZFRyYW5zcG9ydCIsImF1dGhfdGltZSI6IjIwMjAtMDYtMjZUMDA6MzM6NDcuMTQ0WiIsInZlciI6IjEuMCIsInNjcCI6Im9wZW5pZCJ9.qcw8pb9G1ZWWBL0Ywi3256RWxUCawUjHyfkQBrvnseysLhHw4TeAjfD0RRTrLYCzgyexZq-8e-WAkpc_1LovC7MHglkKT_IwhTuAmzZiDsYMjWVBLDq1i8B3PNjsG5P4t1gXH9xf5hrex7eguBwraHhYViwUIJ6ovZWgcs3yFicPoiJls8dsH1MsbhN5vj9EieCtUnPItlesW_pdbww7u016n2YxIdmXI83AuWiy8rQtNZ4cmK_zQefKRz7QL4NveRskt0PAfYFfw6iE-TdGqt535mTv5ddMdIXG8HIgShpsZm-fhbBGHxrXMCe5RkLVRqFBSkiJPOGtW9_Ib6bPWg&token_type=bearer&expires_in=3600&id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5zaUk3eXBnU2dPOFc0SXYtWWdYQk5OMzZHbyIsImtpZCI6Ik5zaUk3eXBnU2dPOFc0SXYtWWdYQk5OMzZHbyJ9.eyJhdWQiOiJkZWJkYjE0OS02NWMzLTRhYzctOTljNS1hY2JmYTU5ZjY2ZDAiLCJpc3MiOiJodHRwczovL2FkZnNxYS5iZWxjb3JwLmJpei9hZGZzIiwiaWF0IjoxNTkzMTMxNjI3LCJleHAiOjE1OTMxMzUyMjcsImF1dGhfdGltZSI6MTU5MzEzMTYyNywibm9uY2UiOiJMVEZsWm5kMlpHZHRRM0ZrYkVKbFRXNVlMVm81T0haTVlWSmtNbEZKZVVoS1gyMVdXRUozWlRGMFNUWksiLCJzdWIiOiJWbzN3Zlp5SGM2bUtKUkRmZXJFN1lYS1piS2RHeGRscFg3MDZmaG5DNlg0PSIsInVwbiI6InNkaWdpdGFsc3NpY2NAYmVsY29ycC5iaXoiLCJ1bmlxdWVfbmFtZSI6IkdBTElMRU9cXHNkaWdpdGFsc3NpY2MiLCJwd2RfdXJsIjoiaHR0cHM6Ly9hZGZzcWEuYmVsY29ycC5iaXovYWRmcy9wb3J0YWwvdXBkYXRlcGFzc3dvcmQvIiwicHdkX2V4cCI6IjY0NDc1NzMiLCJzaWQiOiJTLTEtNS0yMS0yOTk1NTc5MDg3LTM4MTQ3OTIyMjItMzkyNjA5OTA2Ni0xOTIyOTMiLCJhdF9oYXNoIjoiaGJ5LUNPd2hjeGp5S05ycE1DQXd1QSJ9.LXbBATjnRxQt1PmUBMOQBGQ30DZ32clcELarwt_MKel-ghEWARcfauojdW5T1QV08arWCyZp8SJRVNFWwvH-aYM3ilCUObeP8DIXpbfM2h3AP9btACybb8CpaFbLbQJtF-7zNMowZ_FTZ_1vsDDIx2VhYktEMjfXL8xghHV-Ci9NU8wRQPby8FwI0YZ-QzMqzawnXLZx4e9zpjsiI5fuFJFSCO6QQzIn0f6K-uDmalO1-9r8q8e6e_oFmYxS5Pr50FbZjH_1hGyWKZf_dnjcBziwH5O0_v0vdi1DrKiseZey43IhkFGuVIrUvctUmastRJr9-appBz0Z58tSTZks_Q&scope=openid&state=LTFlZnd2ZGdtQ3FkbEJlTW5YLVo5OHZMYVJkMlFJeUhKX21WWEJ3ZTF0STZK

What I want to know is:

  1. What part of the code above is supposed to retrieve and store that access_token that is returned by the identity provider?
  2. Where is it supposed to be stored?

If that #access_token segment that is appended to the redirectUri is not the token that is supposed to be returned when you configure the scope to responseType: 'id_token token', then where should I look for that token?

I really hope you can shed some light on this.

eddy
  • 4,373
  • 16
  • 60
  • 94
  • hi! have you solved the issue? by default the token is supposed be stored in the session storage, you must be able to see it near the id_token, can you see the last one there? – d_f Jul 08 '20 at 23:19
  • Yeah is session storage, I already figured that out. But the docs is not that good and can't figure what does this line of code : `loadDiscoveryDocument` – eddy Jul 09 '20 at 21:22
  • That's an (optional) request to idp to fetch the configuration. It is possible to pre-configure all the necessary endpoints (in most cases the values are the same), supported scopes etc., but the simplest way is to fetch that data directly from idp before the auth request. – d_f Jul 10 '20 at 16:27

0 Answers0