angular-oauth2-oidc
Advanced tools
Comparing version 1.0.20 to 2.0.0
{ | ||
"name": "angular-oauth2-oidc", | ||
"version": "1.0.20", | ||
"scripts": { | ||
"lint": "tslint src/**/*.ts", | ||
"test": "tsc && karma start", | ||
"prepublish": "ngc", | ||
"tsc": "tsc", | ||
"ngc": "ngc" | ||
}, | ||
"version": "2.0.0", | ||
"repository": { | ||
@@ -20,4 +13,3 @@ "type": "git", | ||
"keywords": [ | ||
"angular", | ||
"angular2" | ||
"angular" | ||
], | ||
@@ -28,28 +20,13 @@ "license": "MIT", | ||
}, | ||
"main": "dist/index.js", | ||
"typings": "dist/index.d.ts", | ||
"module": "angular-oauth2-oidc.js", | ||
"jsnext:main": "angular-oauth2-oidc.js", | ||
"typings": "angular-oauth2-oidc.d.ts", | ||
"peerDependencies": { | ||
"@angular/core": "^4.0.0", | ||
"rxjs": "^5.1.0", | ||
"zone.js": "^0.8.4" | ||
}, | ||
"dependencies": { | ||
"base64-js": "^1.2.0", | ||
"js-base64": "^2.1.9", | ||
"sha256": "^0.2.0" | ||
}, | ||
"devDependencies": { | ||
"@angular/common": "^2.0.0", | ||
"@angular/compiler": "^2.4.1", | ||
"@angular/compiler-cli": "^2.4.1", | ||
"@angular/core": "^2.0.0", | ||
"@angular/http": "^2.0.0", | ||
"@angular/platform-browser": "^2.0.0", | ||
"@angular/platform-server": "^2.4.1", | ||
"@types/jasmine": "^2.5.40", | ||
"@types/node": "^6.0.57", | ||
"codelyzer": "^0.0.28", | ||
"rxjs": "^5.0.1", | ||
"tslint": "^3.15.1", | ||
"typescript": "2.0.2", | ||
"zone.js": "0.7.2" | ||
}, | ||
"engines": { | ||
"node": ">=0.8.0" | ||
"jsrsasign": "^8.0.3" | ||
} | ||
} |
235
README.MD
@@ -9,18 +9,40 @@ # angular-oauth2-oidc | ||
## Resources | ||
- Sources and Sample: | ||
https://github.com/manfredsteyer/angular-oauth2-oidc | ||
- Source Code Documentation | ||
https://manfredsteyer.github.io/angular-oauth2-oidc/angular-oauth2-oidc/docs/ | ||
## Tested Environment | ||
Successfully tested with the Angular 2.x and it's Router, PathLocationStrategy and CommonJS-Bundling via webpack. | ||
Successfully tested with the Angular 2 and 4 and its Router, PathLocationStrategy as well as HashLocationStrategy and CommonJS-Bundling via webpack. At server side we've used IdentityServer (.NET/ .NET Core) and Redhat's Keycloak (Java). | ||
## Features | ||
## New Features in Version 2 | ||
- Token Refresh for Implicit Flow by implementing "silent refresh" | ||
- Validating the signature of the received id_token | ||
- Providing Events via the observable ``events``. | ||
- The event ``token_expires`` can be used togehter with a silent refresh to automatically refresh a token when/ before it expires (see also property ``timeoutFactor``). | ||
## Additional Features | ||
- Logging in via OAuth2 and OpenId Connect (OIDC) Implicit Flow (where user is redirected to Identity Provider) | ||
- "Logging in" via Password Flow (where user enters his/her password into the client) | ||
- Using OIDC is optional | ||
- Token Refresh for Password Flow (Implicit Flow doesn't allow for refresh tokens by design) | ||
- Token Refresh for Password Flow by using a Refresh Token | ||
- Automatically refreshing a token when/ some time before it expires | ||
- Querying Userinfo Endpoint | ||
- Querying Discovery Document to ease configuration | ||
- Validating claims of the id_token regarding the specs (aud, iss, nbf, exp, at_hash) | ||
- Hook for validating the signature of the received id_token | ||
- Validating claims of the id_token regarding the specs | ||
- Hook for further custom validations | ||
- Single-Sign-Out by redirecting to the auth-server's logout-endpoint | ||
## Breaking Changes in Version 2 | ||
- The property ``oidc`` defaults to ``true``. | ||
- If you are just using oauth2, you have to set ``oidc`` to ``false``. Otherwise, the validation of the user profile will fail! | ||
- By default, ``sessionStorage`` is used. To use ``localStorage`` call method setStorage | ||
- Demands using https as OIDC and OAuth2 relay on it. This rule can be relaxed using the property ``requireHttps``, e. g. for local testing. | ||
- Demands that every url provided by the discovery document starts with the issuer's url. This can be relaxed by using the property ``strictDiscoveryDocumentValidation``. | ||
## Sample-Auth-Server | ||
@@ -32,7 +54,12 @@ | ||
## Resources | ||
*clientIds:* | ||
- spa-demo (implicit flow) | ||
- demo-resource-owner (resource owner password flow) | ||
- Sources of this lib: https://github.com/manfredsteyer/angular-oauth2-oidc | ||
- Sample Project: https://github.com/manfredsteyer/angular2-oauth-oidc-demo | ||
*redirectUris:* | ||
- localhost:[8080-8089|4200-4202] | ||
- localhost:[8080-8089|4200-4202]/index.html | ||
- localhost:[8080-8089|4200-4202]/silent-refresh.html | ||
## Setup Provider for OAuthService | ||
@@ -88,10 +115,2 @@ | ||
// set to true, to receive also an id_token via OpenId Connect (OIDC) in addition to the | ||
// OAuth2-based access_token | ||
this.oauthService.oidc = true; | ||
// Use setStorage to use sessionStorage or another implementation of the TS-type Storage | ||
// instead of localStorage | ||
this.oauthService.setStorage(sessionStorage); | ||
// The name of the auth-server that has to be mentioned within the token | ||
@@ -106,3 +125,3 @@ this.oauthService.issuer = "https://steyer-identity-server.azurewebsites.net/identity"; | ||
// It dosn't send the user the the login page | ||
this.oauthService.tryLogin({}); | ||
this.oauthService.tryLogin(); | ||
@@ -138,6 +157,2 @@ }); | ||
// set to true, to receive also an id_token via OpenId Connect (OIDC) in addition to the | ||
// OAuth2-based access_token | ||
this.oauthService.oidc = true; | ||
// Use setStorage to use sessionStorage or another implementation of the TS-type Storage | ||
@@ -148,3 +163,3 @@ // instead of localStorage | ||
// To also enable single-sign-out set the url for your auth-server's logout-endpoint here | ||
this.oauthService.logoutUrl = "https://steyer-identity-server.azurewebsites.net/identity/connect/endsession?id_token={{id_token}}"; | ||
this.oauthService.logoutUrl = "https://steyer-identity-server.azurewebsites.net/identity/connect/endsession"; | ||
@@ -154,3 +169,3 @@ // This method just tries to parse the token(s) within the url when | ||
// It dosn't send the user the the login page | ||
this.oauthService.tryLogin({}); | ||
this.oauthService.tryLogin(); | ||
@@ -167,3 +182,3 @@ | ||
import { Component } from '@angular/core'; | ||
import { OAuthService } from 'angular2-oauth2/oauth-service'; | ||
import { OAuthService } from 'angular-oauth2-oidc'; | ||
@@ -217,2 +232,21 @@ @Component({ | ||
You can hook in an implementation of the interface ``TokenValidator`` to validate the signature of the received id_token and its at_hash property. This packages provides two implementations: | ||
- JwksValidationHandler | ||
- NullValidationHandler | ||
The former one validates the signature against public keys received via the discovery document (property jwks) and the later one skips the validation on client side. | ||
``` | ||
import { JwksValidationHandler } from 'angular-oauth2-oidc'; | ||
[...] | ||
this.oauthService.tokenValidationHandler = new JwksValidationHandler(); | ||
``` | ||
In cases where no ValidationHandler is defined, you receive a warning on the console. This means that the library wants you to explicitly decide on this. | ||
### Validate id_token (legacy, deprecated) | ||
In cases where security relies on the id_token (e. g. in hybrid apps that use it to provide access to local resources) | ||
@@ -243,9 +277,67 @@ you could use the callback ``validationHandler`` to define the logic to validate the token's signature. | ||
### Refreshing a Token when using Implicit Flow | ||
To refresh your tokens when using implicit flow you can use a silent refresh. This is a well-known solution that compensates the fact that implicit flow does not allow for issuing a refresh token. It uses a hidden iframe to get another token from the auth-server. When the user is there still logged in (by using a cookie) it will respond without user interaction and provide new tokens. | ||
To use this approach, setup a redirect uri for the silent refresh: | ||
``` | ||
this.oauthService.silentRefreshRedirectUri = window.location.origin + "/silent-refresh.html"; | ||
``` | ||
Please keep in mind that this uri has to be configured at the auth-server too. | ||
This file is loaded into the hidden iframe after getting new tokens. Its only task is to send the received tokens to the main application: | ||
``` | ||
<html> | ||
<body> | ||
<script> | ||
parent.postMessage(location.hash, location.origin); | ||
</script> | ||
</body> | ||
</html> | ||
``` | ||
Please make sure that this file is copied to your output directory by your build task. When using the CLI you can define it as an asset for this. For this, you have to add the following line to the file ``.angular-cli.json``: | ||
``` | ||
"assets": [ | ||
[...], | ||
"silent-refresh.html" | ||
], | ||
``` | ||
To perform a silent refresh, just call the following method: | ||
``` | ||
this | ||
.oauthService | ||
.silentRefresh() | ||
.then(info => console.debug('refresh ok', info)) | ||
.catch(err => console.error('refresh error', err)); | ||
``` | ||
When there is an error in the iframe that prevents the communication with the main application, silentRefresh will give you a timeout. To configure the timespan for this, you can set the property ``siletRefreshTimeout`` (msec). The default value is 20.000 (20 seconds). | ||
### Automatically refreshing a token when/ before it expires | ||
To automatically refresh a token when/ some time before it expires, you can make use of the event ``token_expires``: | ||
``` | ||
this | ||
.oauthService | ||
.events | ||
.filter(e => e.type == 'token_expires') | ||
.subscribe(e => { | ||
this.oauthService.silentRefresh(); | ||
}); | ||
``` | ||
By default, this event is fired after 75% of the token's life time is over. You can adjust this factor by setting the property ``timeoutFactor`` to a value between 0 and 1. For instance, 0.5 means, that the event is fired after half of the life time is over and 0.33 triggers the event after a third. | ||
### Callback after successful login | ||
There is a callback ``onTokenReceived``, that is called after a successful login. In this case, 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 in view of it's claims | ||
(aud, iss, nbf, exp, at_hash) and - if a ``validationHandler`` has been set up - with this ``validationHandler``, e. g. to validate | ||
the signature of the id_token. | ||
well as the id_token, if it was requested. If there is an id_token, the lib validated it. | ||
@@ -261,8 +353,2 @@ ``` | ||
console.debug(context); | ||
}, | ||
validationHandler: context => { | ||
var search = new URLSearchParams(); | ||
search.set('token', context.idToken); | ||
search.set('client_id', oauthService.clientId); | ||
return http.get(validationUrl, { search}).toPromise(); | ||
} | ||
@@ -272,2 +358,66 @@ }); | ||
## Preserving State like the requested URL | ||
When calling ``initImplicitFlow``, you can pass an optional state which could be the requested url: | ||
``` | ||
this.oauthService.initImplicitFlow('http://www.myurl.com/x/y/z'); | ||
``` | ||
After login succeeded, you can read this state: | ||
``` | ||
this.oauthService.tryLogin({ | ||
onTokenReceived: (info) => { | ||
console.debug('state', info.state); | ||
} | ||
}) | ||
``` | ||
### Custom Query Parameter | ||
You can set the property ``customQueryParams`` to a hash with custom parameter that are transmitted when starting implicit flow. | ||
``` | ||
this.oauthService.customQueryParams = { | ||
'tenant': '4711', | ||
'otherParam': 'someValue' | ||
}; | ||
``` | ||
## Routing with the HashStrategy | ||
If you are leveraging the ``LocationStrategy`` which the Router is using by default, you can skip this section. | ||
When using the ``HashStrategy`` for Routing, the Router will override the received hash fragment with the tokens when it performs it initial navigation. This prevents the library from reading them. To avoid this, disable initial navigation when setting up the routes for your root module: | ||
``` | ||
export let AppRouterModule = RouterModule.forRoot(APP_ROUTES, { | ||
useHash: true, | ||
initialNavigation: false | ||
}); | ||
``` | ||
After tryLogin did its job, you can manually perform the initial navigation: | ||
``` | ||
this.oauthService.tryLogin().then(_ => { | ||
this.router.navigate(['/']); | ||
}) | ||
``` | ||
Another solution is the use a redirect uri that already contains the initial route. In this case the router will not override it. An example for such a redirect uri is | ||
``` | ||
http://localhost:8080/#/home | ||
``` | ||
## Events | ||
``` | ||
this.oauthService.events.subscribe(e => { | ||
console.debug('oauth/oidc event', e); | ||
}) | ||
``` | ||
## Using Password-Flow | ||
@@ -329,3 +479,3 @@ | ||
// Login-Url | ||
//this.oauthService.loginUrl = "https://steyer-identity-server.azurewebsites.net/identity/connect/authorize"; //Id-Provider? | ||
this.oauthService.tokenEndpoint = "https://steyer-identity-server.azurewebsites.net/identity/connect/token"; | ||
@@ -342,9 +492,4 @@ // Url with user info endpoint | ||
// set the scope for the permissions the client should request | ||
// The auth-server used here only returns a refresh token (see below), when the scope offline_access is requested | ||
this.oauthService.scope = "openid profile email voucher offline_access"; | ||
// Use setStorage to use sessionStorage or another implementation of the TS-type Storage | ||
// instead of localStorage | ||
this.oauthService.setStorage(sessionStorage); | ||
// Set a dummy secret | ||
@@ -357,8 +502,2 @@ // Please note that the auth-server used here demand the client to transmit a client secret, although | ||
// Load Discovery Document and then try to login the user | ||
let url = 'https://steyer-identity-server.azurewebsites.net/identity/.well-known/openid-configuration'; | ||
this.oauthService.loadDiscoveryDocument(url).then(() => { | ||
// Do what ever you want here | ||
}); | ||
} | ||
@@ -369,3 +508,3 @@ | ||
## Fetching an Access Token by providing the current user's credentials | ||
### Fetching an Access Token by providing the current user's credentials | ||
@@ -396,3 +535,3 @@ ``` | ||
## Refreshing the current Access Token | ||
### Refreshing the current Access Token | ||
@@ -399,0 +538,0 @@ Using the password flow you MIGHT get a refresh token (which isn't the case with the implicit flow by design!). You can use this token later to get a new access token, e. g. after it expired. |
License Policy Violation
LicenseThis package is not allowed per your license policy. Review the package's license to ensure compliance.
Found 1 instance in 1 package
Major refactor
Supply chain riskPackage has recently undergone a major refactor. It may be unstable or indicate significant internal changes. Use caution when updating to versions that include significant changes.
Found 1 instance in 1 package
License Policy Violation
LicenseThis package is not allowed per your license policy. Review the package's license to ensure compliance.
Found 1 instance in 1 package
156203
0
3387
527
4
14
1
+ Addedjsrsasign@^8.0.3
+ Added@angular/core@4.4.7(transitive)
+ Addedjsrsasign@8.0.24(transitive)
+ Addedrxjs@5.5.12(transitive)
+ Addedsymbol-observable@1.0.1(transitive)
+ Addedtslib@1.14.1(transitive)
+ Addedzone.js@0.8.29(transitive)
- Removedbase64-js@^1.2.0
- Removedjs-base64@^2.1.9
- Removedsha256@^0.2.0
- Removedbase64-js@1.5.1(transitive)
- Removedconvert-hex@0.1.0(transitive)
- Removedconvert-string@0.1.0(transitive)
- Removedjs-base64@2.6.4(transitive)
- Removedsha256@0.2.0(transitive)