Say, there are 50 API's which are OAuth protected. What is the best way to monitor each and every one of those api's & their endpoint (say using synthetic transaction)? Please suggest some good open source tool to achieve the same.
Related
SharePoint Online can be accessed either using SharePoint's own native REST API, or, using Microsoft Graph API. I have briefly explored both of the APIs and see differences in terms of the capability, for example, SharePoint API has function type method calls (GetByTitle()), whereas the Graph API seems to support identity based access, or, 'site path'. My opinion is that SharePoint makes it easy to access resources through the use of 'function' in URL, however, i am not sure if it is RESTful. It would be helpful to have your views on this aspect.
Given the two options (SharePoint & Graph) which is the recommended way forward, considering below criteria's:
Future proof - in terms of enhancement, support from Microsoft
Performance
Functionality coverage - considering current version of Graph API
Also, I couldn't find any Microsoft recommendations on this, if there is one kindly share the link.
Thanks.
I recommend Microsoft Graph API. I know it is a proxy to actual Sharepoint, OneNote, Planner, and etc API, but the way they are improving graph api day by day makes me think it is going to last for a good time. Let's say if you are writing an app that wants to connect with many Microsoft apps endpoints, having one class that handles all the graph api requests is enough instead of looking for specific apps endpoints.
Performance: I have been using Microsoft graph api for most of SharePoint related work and it works good and fast. I use Graph explorer to check out the graph if it actually works before implementing it in the app.
Functionality Coverage: Obviously graph is a proxy of a real api so it won't cover all the processes you need to do in SharePoint. For example, I had to create a Sharepoint Group which I could not find a way via graph api. But I assume as more people vote on those requests, the graph api is bringing those new possible proxy endpoints too. But again if your app is only working with Sharepoint then I believe I would stick to SharePoint API. In favor of Graph API, they also have something called delta query and subscription notification to see changes in the files and documents.
I was under the impression that the Graph API was meant to centralize things, make one endpoint to connect to all Sharepoint services via API. With that in mind, I wonder if we shouldn't be asking which is the better option but rather we should be asking when the so-called native option will be end of lifed. Graph is more future proof in the sense that this is the direction MS is taking. I can't speak to performance personally. As far as functionality, I can't imagine that Graph is functionally worse than previous iterations of SP. It might be functionally different. But it should expand API functionality.
https://developer.microsoft.com/en-us/office/blogs/end-of-support-for-basic-authentication-access-to-exchange-online-apis-for-office-365-customers/
Our organization is finding this announcement somewhat problematic! We use an IMAP library extensively to read various service based email accounts in o365. Any guidance on how to address this would be greatly appreciated.
Note, we have many console apps written in .NET (4.8) that run on a server based fired by many scheduled tasks. I understand we'd need to somehow register our "application" (I'm assuming that can be a generic one for our company), but we cannot involve any "user" interaction. These are utility apps. Glancing at the existing sample code for OAuth, they all seem to involve popping up a browser window to get someone to interact with "asking permission" which is exactly what we need to avoid.
We've used IMAP all this time to simply read and parse service based email accounts. I'm not sure I understand why IMAP over a secure connection is "less secure" than a more complex solution. Why take the option away?
On the other hand, the Microsoft Graph API looks significantly more complicated and appears to be OAuth based which, again, seems to involve quite a bit of authentication complexity.
Most REST APIs we've interacted w/ in other .NET console apps use a simple set of API "keys." Why not offer that at least?
As I say, we're looking for a way to write some process that run programmatically to automate a number of operations related to certain mailboxes. IMAP has worked like a charm so far, so we're looking for direct guidance on what to migrate to.
We understand your concerns. While a secure IMAP connection protects the data that's being transported, Basic Authentication exposes your Exchange Online accounts to attack techniques like phishing or brute forcing.
The primary objective of this change is to protect our customers from these threats. In addition, Modern Auth enables admin visibility into app access and enables fine-grained control of these apps.
To answer your question on implementation guidance, there is an existing approach in Graph to achieve exactly what you're looking to do. It's called "OAuth 2.0 client credentials flow". You can read more at https://learn.microsoft.com/en-us/graph/auth-v2-service
(Disclosure - I'm a Senior PM at Microsoft)
We are building our applications in micro-services based architecture to implement our applications. As true with micro-services, we now see a lot of cross service interactions happening between services.
In order to safeguard the endpoints we plan to implement JWT based authentication between such secure exchanges.
There are 2 approaches we see helping us achieve it:
Embed an JWT engine in each application to generate the token (#consumer side) and evaluate (#provider side). With an initial exchange of keys, the token exchange shall work smooth for any future comms.
Have an external (to application) JWT engine, that sits in between all micro-service communications for the distributed application, and takes care of all token life cycle, including its encryption-decryption and validation.
There are lot of options to do it as per option #1 as listed on https://jwt.io but considering the over-head token generation and management adds to a micro-service, we prefer to go with 2nd option by having de-centralised gateway.
After quite some research and looking at various API gateways we have not yet come across a light weight solution/tool that can serve to our need and help us get centralised engine for one applications comprised of many micro-services.
Do anyone know about one such tool/solution?
If you have any other inputs on this approach, please let me know.
I prefer also option 2, but why are you looking for a framework?
The central application should only be responsible of managing the private key and issuing the tokens. Including a framework for solve one service could be excessive
You can also think to implement a validation service, but since applications are yours, I suggest to use an assymetric key and verify the token locally instead of executing remote validation requests to central application. You can provide a simple library to your microservices to download the key and perform the validation. Embed any of the libraries of JWT.io or build It from scratch. Validating a JWT is really simple
If you would need to reject a token before expiration time, for example using a blacklist, then It would be needed a central service. But I do not recommend this scheme because breaks JWT statelessness
Both scenarios could be implemented in Spring Cloud Zuul.
For more info:
http://cloud.spring.io/spring-cloud-static/Brixton.SR7/#_router_and_filter_zuul
http://cloud.spring.io/spring-cloud-static/Brixton.SR7/#_configuring_authentication_downstream_of_a_zuul_proxy
It's now trivial to create a web app that sits atop Parse.com. Now that I have this webapp, I want to expose parts of it to other developers via an oauth accesible api. So, they can develop an app that lets my site users 'give them permission' via oauth and they can now access the api.
How would I start going about doing this?
Update: After #Mubix response, I felt the following clarification would help
Currently I am accessing Parse from the server via a REST api, to get around any javascript security issues re:api keys etc. So, the api would be served of a server other than Parse. Also, the server code is in javascript / nodejs. I came across https://github.com/jaredhanson/oauth2orize which seems a likely candidate, was wondering how others are doing it and if anyone has actually gone a further step and integrated Parse access.
Hmmm .. Intereesting question!
Legal:
First of all their ToS doesn't seem to prohibit what you are trying to do but you should read it carefully before you start.
Implementation:
While parse doesn't provide feature to build your own APIs you could implement something yourself. You could treat the third party developers as users of your app. And you can use the ACL to control access.
Problems:
I don't see any way to implement oAuth entirely within parse.
How will third party apps access your API? Ideally you would like them to use a REST interface but with the parse.com REST API you won't be able to manage access to different parts of your data.
Conclusion:
It seems like too much trouble to implement the API entirely within parse. I would suggest that you write a thin API layer that takes care of auth and uses parse as the backend. You can use one of the service side libraries available for parse. eg. PHP Library, Node Parse.
I'm starting a new system creating using .NET MVC - which is a relatively large scale business management platform. There's some indication that we'll open the platform to public once it is released and pass the market test.
We will be using ExtJs for the front-end which leads us to implement most data mining work return in JSON format - this makes me think whether I should learn the OAuth right now and try to embed the OAuth concept right from the beginning?
Basically the platform we want to create will initially fully implemented internally with a widget system; our boss is thinking to learn from Twitter to build just a core database and spread out all different features into other modules that can be integrated into the platform. To secure that in the beginning I proposed intranet implementation which is safer without much authentication required; however they think it will be once-for-all efforts if we can get a good implementation like OAuth into the platform as we start? (We are team of 6 and none of us know much about OAuth in fact!)
I don't know much about OAuth, so if it's worth to implement at the beginning of our system, I'll have to take a look and have my vote next week for OAuth in our meeting. This may effect how we gonna implement the whole web service thing, so may I ask anyone who's done large-scale web service /application before give some thoughts and advice for me?
Thanks.
OAuth 1 is nice if you want to use HTTP connections. If you can simply enforce HTTPS connections for all users, you might want to use OAuth 2, which is hardly more than a shared token between the client and server that's sent for each single request, plus a pre-defined way to get permission from the user via a web interface.
If you have to accept plain HTTP as well, OAuth 1 is really nice. It protects against replay attacks, packet injection or modification, uses a shared secret instead of shared token, etc. It is, however, a bit harder to implement than OAuth 2.
OAuth 2 is mostly about how to exchange username/password combinations for an access token, while OAuth 1 is mostly about how make semi-secure requests to a server over an unencrypted connection. If you don't need any of that, don't use OAuth. In many cases, Basic HTTP Authentication via HTTPS will do just fine.
OAuth is a standard for authentication and authorization. You can read about it in many places and learn; Generally the standard lets a client register in the authentication server, and then whenever this client attempts to access a protected resource, he is directed to the auth-server to get a token (first he gets a code, then he exchanges it with a token). But this is only generally, there are tons of details and options here...
Basically, one needs a good reason to use oAuth. If a simpler authentication mechanism is good for you - go for it.