I just tried to test wolkenkit’s authentication with the chat template following the wolkenkit docs. User login seems to work, but the user is redirected to Auth0 even when they're already logged in (without the client calling the auth.login method).
Here’s a code snippet from the client:
wolkenkit.connect({
host: 'local.wolkenkit.io',
port: 3000,
authentication: new wolkenkit.authentication.OpenIdConnect({
identityProviderUrl: 'https://<myIdentity>.eu.auth0.com/authorize',
clientId: '<myClientID>',
strictMode: false
})
}).
then(chat => {
console.log("chat.auth.isLoggedIn() = " + chat.auth.isLoggedIn());
console.log(chat.auth.getProfile());
if (!chat.auth.isLoggedIn()) {
return chat.auth.login();
}
});
In package.json, the identity provider is configured as followed:
"wolkenkit": {
"environments": {
"default": {
"identityProvider": {
"name": "https://<myIdentity>.eu.auth0.com/",
"certificate": "/server/keys/<myIdentity>.eu.auth0.com"
},...
Browser log after clearing cookies (I censored the provider identity and the object returned by chat.auth.getProfile()):
Navigated to http://local.wolkenkit.io:8080/
index.js:14 chat.auth.isLoggedIn() = false
index.js:15 undefined
Navigated to https://<myIdentity>.eu.auth0.com/login?client=<clientID>...
Navigated to http://local.wolkenkit.io:8080/
index.js:14 chat.auth.isLoggedIn() = true
index.js:15 {iss: "https://<myIdentity>.eu.auth0.com/", sub: "auth0|...", aud: "...", iat: ..., exp: ..., …}
Navigated to https://<myIdentity>.eu.auth0.com/login?client=<clientID>...
Being redirected although you configured authentication typically means that there is an error in the way the authentication is configured.
You might want to check these settings:
The token must be signed using RS256, not HS256 (which, for some accounts, seems to be the default of Auth0). To find out which signature algorithm is being used, get the token from the browser's local storage and paste it into the JWT debugger. Then you can see how the token was signed. If you need to change the signature algorithm, you can find this in the Advanced Settings of your client in Auth0.
Using the very same debugger you can also verify whether the token and the certificate you are using match each other. If they don't, you probably have copied the wrong certificate, or you have configured the path to point to a wrong certificate.
The certificate file must be named certificate.pem. If it has another name, or the path in package.json is incorrect, wolkenkit should not even start the application, but to be sure double-check that the file is named correctly.
In the package.json, besides the path to the certificate, you also have to provide the name of the identity provider you use, in your case this is https://<myIdentity>.eu.auth0.com/. Please note that this must exactly match the iss claim within the token. Often the claim in the token contains a trailing slash, while the value in package.json does not. If they differ, use the token's value in package.json.
Once you have made your changes, make sure to empty local storage, and to restart your wolkenkit application using the following command (otherwise your changes won't become effective):
$ wolkenkit restart
Hope this helps :-)
Related
We use IdentityServer4 in our .NET solution, which also includes AspNetCore Web API and Angular front-end app.
There are standard middleware settings to setup identity like app.UseAuthentication() / app.UseAuthorization() / etc. (it's actually an ABP framework-based solution). As a result of these settings, all authentication tokens (access_token, refresh_token, etc.) are stored in Local Storage (I have not found where exactly I can select between Local Storage and other kinds, BTW).
Anyway, it has worked somehow in our DEV environment.
But suddenly the need to use window.open from Angular app popped up. This page is a Hangfire dashboard. Which accesses other resources related to dashboard functionality. And it caused a lot of headache: now, to identify user in server page called from window.open we need to use cookies (URL is not considered of course).
does it mean we have to switch fully from Local Storage to Cookies for storing tokens?
how and where to set it up? Or, if it's not too wild and senseless to just copy existing access_token to Cookies - when and where to do that? My idea was to copy access_token when it is created in Local Storage to Cookies and delete when a user logs off and probably under bunch of different conditions, like browser window is closed, etc. (which ones exactly?)
probably to set refresh_token to be stored in Cookies and read it in the mentioned server page, then obtain access_token by it (if it makes sense at all)
UPDATE: i've finally came up with the following, but it does not work. The idea is: when Angular app makes request to back-end and authentication token is already present - the token needs to be saved to cookies. I see the cookies is added. But later on - on next request - it falls into the condition again, because actually the given cookie is not saved:
options.Events = new JwtBearerEvents
{
OnTokenValidated = context =>
{
if (context.SecurityToken is JwtSecurityToken accessToken && !context.HttpContext.Request.Cookies.ContainsKey(accessTokenCookieName))
{
context.HttpContext.Response.Cookies.Append(
accessTokenCookieName,
accessToken.RawData,
new CookieOptions
{
Domain = context.HttpContext.Request.Host.Host,
Path = "/",
HttpOnly = true,
SameSite = SameSiteMode.Strict,
Secure = true,
MaxAge = TimeSpan.FromMinutes(60)
});
}
return Task.CompletedTask;
},
...
}
All apps are web application sharing the same domain. And CORS is set up. AllowCredentials() is called as well when setting up middleware.
client type: Spa
grant type: implicit or code(pkce)
As a user, I want to be able to get silently authenticated if I have already logged with my identity provider. If not stay on the client side just like a guest user. And if I want to login to the client I should be able to get authenticated manually through the login page.
This has both manual sign-in and automatic sign-in scenarios. How would you handle such cases in Open ID Connect?
By adding the prompt=none in client settings will silently get a new token if user has a valid session. But if not I want the user to be able to manually authenticate through the login page upon his/her wish.
If I set prompt=none this will never have any user interaction such as authentication.
tags: Silent authentication oidc, automatic login, SSO
It is quite a deep subject, and the flow typically works like this:
CLASSIC OIDC SOLUTION
User is redirected for each SPA
If signed in already at the IDP there is no login prompt
OAuth state is stored in local storage (though it is recommended to only store actual tokens in memory)
When an access token expires (or before) do an iframe token renewal with prompt=none
When a new browser tab is opened do an iframe token renewal to get tokens for that tab - to avoid a full redirect
When the user logs out remove OAuth state from local storage
The most widely used library is OIDC Client which will do a lot of the hard work for you. See also my blog post + code sample for how this looks visually.
PROBLEM AREAS
It is worth being aware also that iframe silent renewal does not work by default in the Safari browser in 2020. Some notes on this here.
Alternatively, you can use signinSilent(). I have used it on my login page ngOnInit (since AuthGuard will anyway redirect the user to login, I thought it will be the perfect place in my scenario).
// login.ts
ngOnInit(): void {
this.authService.signinSilent().then(_ => {}).catch(_ => {});
}
// authService
public signinSilent() {
return this.userManager.signinSilent();
}
signinSilent method will return the user object if user already has a valid session with idp. else it will throw an error, probably login_required.
Goal
Using googleapis with firebase functions. Get a JWT token so firebase functions can use a service account with domain-wide delegation to authorize G Suite APIs like directory and drive.
Question
What goes in path.join();
What is __dirname
What is 'jwt.keys.json'?
From this example:
https://github.com/googleapis/google-api-nodejs-client/blob/master/samples/jwt.js
// Create a new JWT client using the key file downloaded from the Google Developer Console
const auth = new google.auth.GoogleAuth({
keyFile: path.join(__dirname, 'jwt.keys.json'), // <---- WHAT GOES IN path.join()
scopes: 'https://www.googleapis.com/auth/drive.readonly',
});
Error
When I run
const auth = new google.auth.GoogleAuth({
keyFile: path.join(__dirname, "TEST"), // <-- __dirname == /srv/ at runtime
scopes: 'https://www.googleapis.com/auth/drive.readonly',
});
From the GCP Logs I get this error:
Error: ENOENT: no such file or directory, open '/srv/TEST'
Obviously TEST isn't valid, but is '/srv/?
What is the keyFile, a file path? a credential?
Another Example
https://github.com/googleapis/google-api-nodejs-client#service-to-service-authentication
I found documentation here:
https://googleapis.dev/nodejs/google-auth-library/5.10.1/classes/JWT.html
If you do not want to include a file, you can use key, keyId, and email to submit credentials when requesting authorization.
You seem to have a lot of questions around how this works. I would strongly encourage you to read the basics of Google authentication.
JWT is short for JSON Web Token. It is a standard standard defining secure way to transmit information between parties in JSON format. In your code "jwt" is a class containing a keys property. There are a ton of JWT libraries. There are some popularly packages using Node/Express frameworks.
__dirname // In Node this is the absolute path of the directory containing the currently executing file.
path.join is a method that joins different path segments into one path.
Here you are taking the absolute path and concatenating some piece of information to the end of the path. I am not certain what is contained in jwt.keys.json but that is what is being appended to the end of the absolute path in this case.
Without knowing your project structure or what you are pointing to it's not really possible to say what is and is not a valid path in your project.
keyFile is a key in an object (as denoted by the {key: value} format) under google.auth. As seen in the sample code you referenced, the script is taking the google.auth library and calling a method to construct and object with the information to are providing so that it abstract away other elements of the authentication process for you. You are giving it two pieces of information: 1) The location of the keyFile which presumably are the credentials and 2) The scope or set of permissions you are allowing. In the example it is readonly access to Drive.
EDIT: The private key file that the calling service uses to sign the JWT.
I have a JavaScript file that needs to use the GitHub API to get the contents of a file stored in a repository.
I am using GitHub.js to access the API, and it shows the following method for authentication:
// basic auth
var gh = new GitHub({
username: 'FOO',
password: 'NotFoo'
/* also acceptable:
token: 'MY_OAUTH_TOKEN'
*/
});
This code will be viewable inside the repository, as well as in the developer settings in the browser. GitHub does not allow you to commit a file that contains an OAuth token, and publicly displaying the username and password for my account is obviously a non-option as well.
Is there any other way to do authentication? I tried using the client-id and client-secret but it doesn't seem to take those as valid credentials.
Try an Installation Access Token. I can't remember the specifics but I used that link to set myself up.
I'm attempting to setup a prototype API using nodejs that uses 3Scale's API management.
I've been able to find their plugin intergration code, which is as follows:
var ThreeScale = require('3scale').Client;
// keep your provider key secret
var client = new ThreeScale("X");
// you will usually obtain app_id and app_key from request params
client.authrep({ app_id: "Y",
app_key: "Z" }, function(response){
if(response.is_success()) {
// continue
} else {
throw new Error("not authorized " + response.error_message);
}
});
Which makes some sense to me as part of a server module. But, I'm not sure where the client's credentials are in that equation....
I see it as the client is pointing to your app, and here's the password for the app...but what about the username/password for the actual client!? where does that get checked?
I feel like I'm not grasping their architecture (possible because it's my first real node project and definitely my first time using 3Scale)...
Further, what's a client's request then look like?
in 3scale system app_id and app_key (in this authentication method) kind of represent the user's (i.e. developer's) credentials. This is due to the fact that every user can have more than one application and one application belongs just to one user, so you don't need user credentials. The credentials are checked on the 3scale system side and if authorized, they report the usage and forward the call to your API.
provider_key identifies your account (API owner) and you have to keep it secret (if someone gets it, they can impersonate you).
Did you already check the 3scale's support site? There are many useful information on the system architecture, some tutorials on integration, etc.
You can check them here: http://support.3scale.net
btw. the node.js plugin is a community plugin. You can also try integration via nginx reverse proxy.