My company would like to make use of StackOverflow as a forum where developers can ask technical questions about our REST APIs. I found that there is a principle of "branded tags" (e.g. stackoverflow.com/questions/tagged/your-company-name) that we could use to guide our customers to StackOverflow. From experience we know that a lot of developers publicly start sharing their private API keys (which are part of the URL by design) when they are posting questions. As API keys should be kept confidential, I would like to check how StackOverflow prevents developers from publicly sharing their API keys when posting a question. Alternatively, can we (as a company) do something to prevent this?
Many thanks!
Related
I don't intend to collect any user data from my Google Assistant app.
So I am in need of a minimal Privacy Policy, but I am unsure of the data collected by Google's Dialogflow, and how I am supposed to mention that in the Privacy Policy.
I am not a lawyer, and asking legal questions on StackOverflow is not terribly wise in general.
However - the Google reviewers are primarily concerned with what you are specifically doing and collecting. Users have already agreed to Google accessing their information.
You can reference Google's API Terms of Service (which you agreed to when you used Dialogflow) which describes how they will use user information.
I'm trying to find if a RP(Relay Party) and OP(OpenID Provider) can be on the same domain. We have a use case to implement internal SSO in the future and have being asked to implement authorize on the same domain for each client.
We have a total of 3 domains and the ask is to implement authorize for each. This means each RP will be it's own OP. Apparently this solves an issue with two of the 3 clients, something to do with sessions.
I think this is a bad approach, but I can't find any doc's or case studies to strengthen my argument.
This seems like a misuse of the spec. My reasons for thinking this are:
I can't find any example online where somebody else has called authorize on the same domain
I can't find any reference in the doc's to say you can or can't
Within the FAQ it says:
It lets app and site developers authenticate users without taking on the responsibility of storing and managing passwords in the face of an Internet that is well-populated with people trying to compromise your users’ accounts for their own gain.
Given we are calling authorize on the same system we still have the responsibility of storing and managing passwords.
Questions
Is there any doc's to support or reject this use case of OpenId Connect?Do you know of any examples where it's being done?
Many thanks!
It's not the typical use case for OIDC but I don't think it's a terrible idea. There's nothing in the spec that says you can't use OIDC on the same domain.
From what I can tell, Google has implemented their own OIDC-like flow for all of their products and they all run under the google subdomain.
I'm building an app that requires authentication and I'm worried users might want to be able to remotely log out. Is there a way to use JSON Web Tokens and be able to blacklist or reject them? I understand that their benefit is statelessness, but it would be nice to have a remote logout.
EDIT: With Express.js using the express-jwt module, there is a method to revoke tokens. Also, there is a module express-jwt-blacklist. I still don't understand how these strategies work and would like to know what is the best practice at this point.
There is a nice article on Auth0 about
Blacklisting JSON Web Token API Keys where they give a good real world example on how to blacklist a JWT API key so it is no longer valid. You should give it a read.
Framing the problem
Providing support for blacklisting JWTs poses the following questions:
How are JWTs individually identified?
Who should be able to revoke JWTs?
How are tokens revoked?
How do we avoid adding overhead?
This blog post aims to answer the previous questions by leveraging our
experience from implementing this feature in our API v2.
The article breaks down each point and then shows some example code on how to achieve it and concludes with:
Most of the aforementioned content applies to blacklisting JWTs in
general, not just JWT API keys.
Hopefully this blog post has provided some useful ideas on how to
tackle this problem.
I've personally applied similar methodologies to revoke multiple sign ins where the tokens were used similarly to session ids and stored in cookies. I modeled it like the GitHub profile section where you the user can see all your other active sessions and revoke them (remote sign out) when needed.
As far as best practice is concerned, I believe that topic would be rather opinion based. I do however see Auth0 as source of good practices in this topis area with a lot of people experienced on the matter.
UPDATE:
Found this express-jwt plugin for token blacklisting on npm
In my current work, I have to develop an intern REST API engine.
I have read the Roy Fielding thesis, documented myself, and I finally got something that works great easy to use, with high performance, corresponding to the Fielding REST spec.
There is only one point that I dont really know how to overcome : the security problem.
Again, I documented myself, and I wanted to use OAuth2.0 in my engine.
The problem is that I dont understand nothing at all how to use this protocol.
I dont understand how the consumer can connect himself and be recognized by the server.
I dont understand if I have to provide API key to my consumer(like Facebook, Twitter and Google make it) or if a token will automatically be generated if I send a login / password to the server
I dont know if I have to create my own OAuth2.0 server that provides keys, or if OAuth2.0 libraries are sufficient to provide security.
In fact, I dont understand nothing at all with OAuth2.0, and I need to learn. The problem is, every documentation that I try to read is like chinese, I didn't find an easy one, step by step that will help me with this.
That's why I post here, can you help me understanding a bit more OAuth2.0 and the secured authentication for API ?
I willingly didn't speak about the technologies, because I want to understand OAuth2.0 before applying it technically.
Thanks for all
The main problem with OAuth (both versions) is that you'll see a lot of talk about the three legged version. That is when you have user, a data-providing service and a consuming service, let's say a service that will create physical copies of your flickr photos. In this case the OAuth flow allows the user to tell flickr that the third party can access their data. This is not the scenario you are after, you are interested in 2-legged OAuth, see here for a description.
Of course you could look at other methods too. I've used HAWK in a number of REST/Hypermedia APIs and found it to be great to use in both nodejs and .NET server stacks.
Thank you for your answer, I studied a bit more OAUth2 en tried to implement it with 3 stragery : basic, clientPassword, bearer.
I created a new thread for an other problem, if you want to take part of it :
OAuth2 server creation with nodejs
I created a number of posts on behalf of the user by issuing an HTTP POST request to (PROFILE_ID/feed) with the publish_stream. Sample:
https://graph.facebook.com/me/feed?
I got everyone's post ids, but I when I'm trying to access and read them I getting a "false" respond..
I was at a Perl Mongers meeting (Los Angeles) last week where the presentation was on integration with Facebook. In particular, one of the developers was discussing his new module, Facebook::Graph. He indicated that in producing the module he learned a lot about what Facebook would do if you request information but don't provide everything it is expecting in your request. Your problem description sounds like a case in point.
The module's description is:
This is a Perl interface to the Facebook Graph API
http://developers.facebook.com/docs/api. With this module you can
currently query public Facebook data, query privileged Facebook data,
and build a privileged Facebook application. See the TODO for all that
this module cannot yet do.
There is a companion POD for that module called Facebook::Graph::Cookbook. It contains a couple of cookbook examples.
While the module is still fairly new and under development, I know that the individual who worked on it has spent many hours working on it in a professional setting where solid results are expected. I'm confident that he "got it right." It's currently being used by a high-traffic well known website.
There's no point trying to re-implement interfacing with this API when someone else has done a good job of it already. Through the discussion that took place after the presentation I know that the module has gone through extensive testing. That's not to say it's perfect, but it's probably a hundred or more man-hours further along the journey.
It's my suggestion that you implement your Facebook Graph interactions through using this module. I suspect when you do, many of your headaches will go away.
You'll need to ask for the read_stream permission to do this