I'd like to make a connection to a Solace broker using the OAUTH Client Credentials Flow. I have the client secret, client id. At the risk of asking a dumb question, is there a NodeJS sample somewhere with something like this? I started with Google and went to the Solace Codelabs with the tutorials, but didn't see anything for this. I could have sworn that I read that Solace only supports this with MQTT, so I'm not even sure the NodeJS SolaceAPI will work with this approach.
I have a client id, client scope, and secret. However, the Solace NodeJS API seems to take an access token. As I understand the OAUTH flow, the access token comes from the authorization server, so this would be a separate step. It sounds like I'm being asked to fetch the access token on my own, in some manual way, then, pass that result onto Solace. Because that seems like extra work, I assume I didn't understand something. I would hope this would be, I don't know, simple. Something like, hey here's my OAUTH credentials, you, Solace, go and do whatever you need to get to the correct point.
Thanks,
Woodsman
Related
We have a service that sends delivery notification messages to a client via HTTP requests - meaning, the client must also act as a Server (must expose an HTTP endpoint) in order to receive these notifications.
Some of our clients are asking that our requests authenticate against their endpoints via OAuth. We would prefer to implement this using a third-party so as to avoid having security features implemented in-house (and avoid security issues/not well-handled edge cases that we could end up introducing); More specifically, we'd prefer to have a reverse-proxy.
The idea would be that our service would send a request to the client through the reverse proxy, which would identify that the request is missing a token and would be responsible for getting a token and injecting it into the request.
I googled for this but couldn't find anything; perhaps I'm not searching for the correct keywords. Is there a packaged/"market" reverse-proxy solution for this? Or perhaps a programmable reverse-proxy that could bootstrap a solution for us?
I can see two approaches for this:
have an oauth2 client library in your own code to handle the oauth2 authentication flow for your app. Most programming languages have an oauth2 client so you wouldn't re-implement anything and have a secure authentication mechanism,
use a proxy that implements an oauth2 client so it would do that part of the flow for your service but I'm not sure it exists. I couldn't find anything also related to this because of the fact that most of the languages have an oauth2 client that's readily available.
I hope you find the solution to your problem :)
I am novice to how oauth2 with JWT works But must to learn it in short time :) After reading bit I draw a conclusion abstract of its work as this.
now I have two question in my mind.
(1) Is my way of understanding of how OAth2 work is fine ?
(2) As far as I know after step 6 (diagram) no further request to authorization server. Then,anyone(intruder) know the token witch given by auth server can communicate to the web API and obtain unauthorized access.how does is not possible.
(I know that token not alter by intruder since then web api new that but without altering it still intruder can communicate to web api)
I know I have miss something please kindly show me where I have missed ?
You have to take security measures to protect your token from being stolen. This is no different than preventing session-id from being stolen in session based authentication.
Anyone with access to a valid token is by definition an authenticated user, no matter how the token was retrieved.
Whether your web API communicates with the authentication system directly is not relevant.
I'm trying to implement an OAuth2 provider for my web service.
It seems easier to implement the Authentication Server together with the Resource Server. The specification doesn't say anything about the communication between them.
Does anybody see a reason not to do this?
I had a post yesterday regarding this issue. I hope we can mutual answer each other. First to directly answer your question, I think it depends very much on the load that your app has to handle. If you have to scale your app to many resource servers, keeping a separate auth server is the best because you can centrally manage user credentials and access_token in one place.
Here is my question. I believe if you have tried something similar to mine, you can give me some suggestions.
OAuth - Separating Auth Server and Resource server returns invalid token when accessing protected resource
I'm developing an API which only needs to be accessed by servers, as opposed to specific, human users. I've been using the client credentials grant which, if I'm not mistaken, is appropriate for this use case.
So the remote websites/apps, after registering their corresponding OAuth2 clients, are simply requesting an an access token using their client ID/secret combination, via a SSL POST request + HTTP Basic authentication.
Now I was wondering if it would be a good idea, during said access token request, to check the remote IP to make sure it actually belongs to the client that was registered (you'd have to state one or several IPs when declaring your app, then it would be checked against the remote IP of the server making the POST /token request).
I feel like this would be an easy way to make sure that, even if the client ID/secret are somehow stolen, they wouldn't be just usable from anywhere.
Being fairly new to the OAuth2 protocol, I need some input as to whether this is a valid approach. Is there a more clever way to do this, or is it straight up unnecessary (in which case, for what reasons)?
Thanks in advance
That's certainly a valid approach but binds the token tightly to the network layer and deployment which may make it difficult to change the network architecture. The way that OAuth addresses your concern is by the so-called Proof-of-Possession extensions https://datatracker.ietf.org/doc/html/draft-ietf-oauth-pop-architecture.
It may be worth considering implementing that: even though it is not a finalized specification yet, it binds the token to the client instead of the IP address which safeguards against network changes and is more future proof.
Question
Is it possible to use OpenID login using only client side technologies?
Basicly I want to implement OpenID for steam login, I have found very few examples online, mostly in PHP using pre existing libraries.
My goal is to create a client side only solution using only Javascript and HTML. The understanding I have of OpenID is very limited so any resources to better help me understand would also be very welcome.
Any help is appreciated.
I have looked over http://openid.net/developers/libraries/ and found http://kjur.github.io/jsjws/ but I am unsure if it will work outside of a server envrionment.
You could do that, yes. But then your server will not have any way to verify the data the client sends you.
If you really trust the client, this might be fine. But the normal OpenID process only trusts your own server and the remote OpenID server, but not the client - which is why your server calls back to the OpenID server after the client told your server the login.