I am trying to get Swagger UI to successfully authorize to a oidc-provider instance.
I have set up a minimal (as possible) instance on glitch here: https://glitch.com/~copper-vise
What it does is:
have swagger UI on /doc serving the definition from the swagger.yaml file
run the oidc provider with minimal configuration and dev interactions.
The problem is that I don't seem to be able to get the two work together. It seems like it could be a Swagger UI bug, but considering my lack of experience with oidc it might simply be a configuration issue.
To try, click the "Authorize" button on the swagger interface, use foo and bar for the client_id and client_secret, check at least the openid scope and click "Authorize". At this point you should get a login prompt. Enter anything you like and login. At this point the swagger UI should be having a token, but I never got it that far.
What I'm getting instead is a invalid_client error, it seems like the oidc-provider expects an authorization request header that the Swagger UI is not providing. The "implicit" flow does not seem to work at all either. As far as I can tell, these are the two flows that the oidc-provider supports (with this configuration?).
I'm stuck, not sure where to go from here. It seems like the right combination of the openapi securitySchemes configuration in the swagger.yaml file and the oidc-provider and client options should get this running.
It seems swagger is sending client_secret_post client authentication, the default on the IdP is client_secret_basic. If you change the client configuration on the IdP to match the scheme the client is actually using it'll work.
Related
My problem is that the oAuth gets denied on our test server but it works on our live and development (local) servers.
Is there something specific what I have to configure to make it work on antoher server?
I compared the platform folder with test and live, both are identical.
I created same oAuth logins on both servers, didn't work.
I tried to login through the ip, to avoid apache, didn't helped.
Now I am kind of lost where to look next.
To test my login I use Swagger or Postman with this url: https://test.shop/authorizationserver/oauth/token with Basic Authorization.
The reponse is: {"error":"invalid_client","error_description":"Bad client credentials"} but it is wrong.
This is the configuration for the user:
I had besides this problem, an equal one on the live system. Our apache removed the Authorization from the header to get the Backoffice working, which is protected through the htaccess. When I was researching this problem, I got the same error as this one. Now everything works fine on live. I corrected the same thing on test, tried even uninstall apache, but the login is still not working.
You need configure oAuthClient for SmartEdit by running following Impex:
INSERT_UPDATE OAuthClientDetails;clientId[unique=true];resourceIds;scope[mode=append];authorizedGrantTypes;accessTokenValiditySeconds;authorities;clientSecret;;smartedit;hybris;basic,permissionswebservices,previewwebservices;password,client_credentials;3600;;;
For details, please see:
Configuring oAuthClient for SmartEdit
Can you please check if the configurations are similar? If yes then there is something env specific and needs to be debugged individually.
We fixed the problem by pasting the correct "OAuth client secret" into the "Password" and "Verify password" field. This was initialized via impex with an old value (but not visible to the user in the dialog as seen in the lower screen).
I'm relatively new to the modern JavaScript web development world. I've built a very simple Node/Express back-end and a separate React front-end. My vague plan is to have users that will have permission to access certain areas of the front-end, and then have the front-end make requests to the back-end. Can the front-end and back-end share the same authentication/authorization scheme? Can they both use something like Auth0? How can I make these two secure?
I'm a little stuck and would appreciate any advice or a nudge in the right direction. I'm mostly stuck because these are two separate applications but the same "user" would technically have permissions to certain React views as well as certain Express endpoints - how they moosh together?
Thanks.
Although seems not directly related to your topic, but I would actually suggest you try Meteor if you are not planning to immediately start working on large projects (not pressing too hard on scalability).
Meteor has a builtin support for Accounts and interacts with MongoDB nicely, and it also has its own DDP protocol that simplifies API call massively. It also interacts nicely with React.
If you think Meteor might not be a good choice for yourself, you could still learn from its design policies of authorization, etc. It has quite a bit package source code that are not too difficult to understand, and should be helpful for you to learn the basic idea. (Actually, Meteor's Accounts package already implements the basic idea mentioned by another answerer, you can learn from its design principles)
When users log in to your site, issue them with an access token that they keep client side. On front-end, check if user has token and correct permissions before rendering components. On back-end, send the token as request headers to the endpoints.
I have implemented a similar case, but with the spring boot kotlin at the backend instead. My solution is using JWT token to validate the authentication and authorization.
User logins by input login form and send POST method to backend via a REST API.Backend validates credential and returns the JWT token including encrypted user_role, expiration date, etc... if valid or 403 exception
Front-end decodes the JWT (using jwt-decode lib or something else),
save it to validate the access permission to specific page in the
website based on user_role. Eg: role='ADMIN' can access to admin dashboard page, role='USER' can access user profile page, etc.
If you use express as the backend, I suggest to use the feathersjs. It has backend solutions for this and an optional front end version. Refer: https://docs.feathersjs.com/api/authentication/jwt.html
Secure Front end (React.js) and Back end (Node.js/Express Rest API) with Keycloak follow this
Overview: I am trying to understand the interactions between OAuth security in my server and in my chrome extension. I think I have 90% of the answer working, but I'm missing a bit. I'd like to find the cleanest way to finish my implementation using existing tools, rather than reinventing any wheels.
Background: I have a node.js app that uses passport, passport-google-auth, and express-session to authenticate users. I save per-user information, keyed by the user's Google identity. This works fine. My web pages can exchange data with the app, and the Google login screen pops up correctly in exactly the cases I'd expect.
I also have a chrome extension, which includes a browser_action popup that needs to write data to my node.js app and a content_script that needs to read data from my app.
My extension already uses chrome.identity.getAuthToken to get the user identity.
For testing, if I ignore security, I can pass this id to my node.js app, and access the info I need.
But, this is no good, of course. I want my node.js API to be locked down, only letting in clients that have the cookie generated for me by passport.
Side note: I imagine, instead, that I could do some song-and-dance wheel reinvention and pass the id securely to my server via https. But this seems completely wrong, right?
Question: I assume that my chrome extension really should be doing the OAuth2 dance directly with my node.js app. But, I don't know what piece I should be using, or how to cleanly play with chrome.identity. I suspect that I'm just missing a small bit of wisdom, but I don't know what it is.
Side comment: Because cookies are shared between browser tabs, I can (clumsily) achieve what I want by simply connecting to my node.js app from another tab in the browser. So, I guess I just need to get the same behavior from my extension background page.
It looks like the easiest answer for me was to use the Stormpath APIs for this. It took some effort, but was reasonably straightforward.
I have been reading a lot about how to implement a full authentication and authorization system in Asp.Net Web Api 2 which includes registering, sending email confirmations, issuing both access tokens and refresh tokens, etc. I have successfully done all of that after all, however, it looks such an un-necessary over head to have to do it for every single project.
I am still not sure, but I believe the "Thinktecture IdentityServer" is a package that has been put together to provide all of this, am I right?
If yes, can anyone tell me (in a very straight forward way) how can I create a new Web Api project and easily get all the above mentioned features using this package?
Thinktecture identity server v3 is a collection of highly configurable modules, so there is a fair amount of code to write to set it up how you want it. The Thinktecture wiki has a good 'hello world' example that might be enough to get you going:
Hello world
After that, download the samples, find the one that most closely matches your situation, and build upon that. In particular, you'll want to set up a database to save your registered users to. The related 'MembershipReboot' project is generally the one you use to do data access, along with the 'MembershipReboot.Ef' addon that will autocreate your database using EntityFramework.
MembershipReboot is where you set up which email events you want to use.
Email config in membership reboot
Here's To USE the identityServer3 that you set up separately:
(IdentityServer3 has some out of the box server-setup examples that may be good enough for you, or might only need a slight configuration)
Nuget the Microsoft OpenID Connect (I think its called: Microsoft.Owin.Security.OpenIdConnect)
Point the OpenID Connect middleware (also in Startup.cs) to the IdentityServer.
app.UseOpenIdConnectAuthentication(new OpenIdConnectAuthenticationOptions
{
Authority = "https://myIdsrv3Path/identity",
ClientId = "myapi",
RedirectUri = "https://myIdsrv3Path/", // or
ResponseType = "id_token",
SignInAsAuthenticationType = "Cookies"
});
In the IdentityServer3 set the accepted clients to include "myapi", with the claims you need.
There is more to explain about authorization, but this answers your basic question for securing an api.
See the IdentityServer3 documentation:
https://identityserver.github.io/Documentation/docsv2/overview/mvcGettingStarted.html
Scroll down to the section called: Adding and configuring the OpenID Connect authentication middleware.
Im using GWT, GAE to make a web app.
I looked at a bunch of tutorials regarding implementing a login system but most of those tutorials implement it so it's mandatory to login to access the web app. How would I go about making it so that anyone can access the app but if they want to use account specific functionality, they they have the option of signing up for an account.
There are two parts to it.
First, in your client code you check if a user is logged in. If so, you allow access to the "closed" parts of the app. If not, you show a link/button to login and hide tabs/views that are accessible to authorized users.
Second, in your server code you specify which requests do not require authentication and which do require it. This is necessary if a user somehow figures out how to send a request without using your client code.
For example, in my code some requests have checkSession() called at the very beginning. If no authentication object is found for this user in session, this method throws LoginException to the client. If the authentication object is present, the request continues to execute normally and returns requested data to the client.
Further to Andrei's answer, if you want a framework to manage the sessions for you, you can use GWT-Platform, which has an excellent Gatekeeper feature.
I use it for mine and I have a LoggedInGatekeeper class. Simply add #UseGatekeeper(LoggedInGatekeeper.class) to the constructor of each presenter proxy and it checks if the user is logged in. If you want anyone to be able to access that page simply annotate with #NoGatekeeper. Easy!
It takes a bit of setting up but it's a great MVP framework. There are maven archetypes and samples etc.
Hope this helps.