For a project I`m using this library: angular-oauth2-oidc for Support in OAuth 2 and OpenId Connect (OIDC) in Angular.
I have everything set up and all is working fine.
MainComponent File:
export class MainComponent implements OnInit {
constructor() {
this.configureSSO();
}
configureSSO() {
this.oAuthService.configure(authConfig);
this.oAuthService.tokenValidationHandler = new JwksValidationHandler();
this.oAuthService.loadDiscoveryDocumentAndTryLogin().then(() => {
// the lib received the access_token as well as the id_token, if it was requested.
// If there is an id_token, the lib validated it.
// DO STUFF WITH TOKEN HERE
});
}
}
authConfig File:
import {AuthConfig} from 'angular-oauth2-oidc';
export const authConfig: AuthConfig = { /...SOME CONFIG HERE .../ }
AuthGuard File:
@Injectable()
export class AuthGuard implements CanActivate {
constructor(private router: Router, private oAuthService: OAuthService) {
}
canActivate(): boolean {
if(this.oAuthService.hasValidIdToken()){
return true;
}
return false;
}
}
After a successful Login on the OIDC Providers Site, I can see the access_token being saved in the Session Storage of my local Browser:
This all works perfectly, BUT, if I now proceed to change the token in the Session Storage, I'm still able to get into my protected routes. Although the access_token
was altered.
Same thing when id_token
is changed.
--> The AuthGuard still lets me go to my protected Routes.
Can anybody enlighten me on how this would be possible?
I'm not able to find anything about how this is handled internally in the docs Documentation angular-oauth2-oidc
I'm quite sure it is NOT an Implementation Fault, but rather that the library saves the token somewhere internally, and uses the unaltered token instead, as everything else works as expected perfectly.
But WHY save the token in the Session Storage anyway if it is not (really) used?!?
More:
If I actually delete the whole token from the storage, all blocked Routes are actually blocked - which is good!
Same thing happens when I alter the Expiration Time (exp) inside the JWT to something before the actual time.
So these two checks are actually working fine, but when changing access_token
or id_token
the AuthGuard still gets a valid Token... (maybe from inside the lib?!?)
I think there's something I don't understand about JWT in general, and why they are even saved in local/session Storage, or why the change to them does have no effect...
Any answers are greatly appreciated.