Based on https://developer.microsoft.com/en-us/graph/blogs/upcoming-changes-to-exchange-web-services-ews-api-for-office-365/ basic authentication for EWS will be deprecated.
There is nothing in the article that references IMAP though and I am wondering if it will be deprecated for office365 since it uses basic authentication.
From what I've heard about SMTP, basic authentication will never go away since it is part of the protocol itself. I would imagine IMAP4 is similar in that respect.
It is best to see what Microsoft itself does - when (and if) they will start supporting XOAUTH2 authentication in their own products (Exchange and Outlook), then you'd need to start worrying about the Basic authentication. So far, this has not happened.
Related
Our existing customer base is in peoplesoft and we are developing lot of mobile applications. Hence, we would like to use oauth 2.0 for authentication and authorization, but i cannot find any way to integrate the two.
Does PS implement OAuth? If they don't then you'll be out of luck. A quick search indicates they support SAML for SSO (on their web sites). You will probably have to describe a little bit more what you are doing, and why you think OAuth is the way to go.
Note that being mobile doesn't necessarily mean you have to implement OAuth.
This is a very late answer, but as of PeopleTools 8.58, PeopleSoft applications support OAuth2 for REST services. The caveat is that only Oracle IDCS is able to be used as an authorization server. There may be a plan in the future to support other authorization servers.
Cf. https://blogs.oracle.com/peopletools/what-peoplesoft-is-doing-with-oauth2-in-858 and https://support.oracle.com/knowledge/PeopleSoft%20Enterprise/2621182_1.html for more information.
I am building a REST API using Grails. I want it to be protected using OAuth2.0 client_credentials flow(grant_type). My use-case is as follows:
a external agent will send a request to something like
http://server-url/oauth/token?client_id=clientId&client_secret=clientSecret&grant_type=client_credentials
and obtain a access_token. Then, my URL(protected resource) should be accesible with something like
http://server-url/resource?access_token={access-token obtained before}
I am looking for something that makes doing this on Grails easy and quick. What will be the best way/tool/plugin to use for this ? Scribe library is an option, if there are any tutorials for my specific use-case, it will be great.
P.S.: I have tried the spring-security and related plugins, no joy there. Any alternatives would be nice.
I have the same issue. I found a lot of grails plugins that helped you authenticate your app against other oauth providers, but nothing that would help me make my app the oauth provider. After a lot of digging, I came across this grails plugin that will do exactly what you want.
https://github.com/adaptivecomputing/grails-spring-security-oauth2-provider
I'm still configuring it for my application, and I think the docs might need a few edits (specifically the authorization_code flow) but I got the simple client_credentials flow to work with minimal configuration. Hope that helps!
Based on my experiences, Scribe was built for OAuth 1.0 and has only very limited support for OAuth 2.0. In fact, for testing our own OAuth 2 implementation, all we could use from it was an HTTP request wrapper, we had to do anything else manually. Fortunately, doing it manually is suprisingly easy.
Since I still haven't found a fine open OAuth 2.0 library for Java (frankly I'm not familiar with Groovy), I encourage you to write the client code for yourself. You don't even need a client callback endpoint to use the client credentials grant flow. So you simply create an HTTP request (as you've written above already, take care to escape the GET parameters though) and get the response content. Your flow does not use redirects, so simply parse the JSON object in the response content, e.g. with the org.json library. Finally, send an HTTP request using the extracted access token.
Note that your examples are not completely standard compliant. The standard requires using HTTPS, sending the token in an HTTP header instead of a GET parameter and suggests using a HTTP basic authorization header instead of GET parameters to specify client credentials.
I may have misunderstood your question, and you may want to implement the server side, too. The scribe library supports only client side, so you can find a commercial implementation or implement your own server. It is a complex task, but if you support only the client credentials flow, it almost becomes easy. ;-)
This isn't a plugin, it's just a sample Grails application that acts as an OAuth provider. It was really easy to get up and running with Grails 3.
https://github.com/bobbywarner/grails3-oauth2-api
I need to develop an API to be the core of a web APP.
My initial idea was making a REST API that would treat all the request and then create some clients for web, mobile and desktop.
My question is, How should I manage the authentication for this situation?
I thought about using a token that would be passed with all requests to the REST API.
Im my case, I would not like to have something like OAuth because the ecosystem will not have multiple apps like Facebook/Twitter does.
NOTE: I must have the API separated from the client for web.
In more details, I would request POST /users/auth passing their password and username, and receive an auth token.
Is it a good approach or there is something better?
Agree that Devise is great for the auth in the application. For the API level, 3scale could help a lot (http://www.3scale.net) - it takes care of rate limits, keys, oauth secret distribution, analytics, developer portal and other stuff. There's a ruby plugin to get started here: https://github.com/3scale/3scale_ws_api_for_ruby.
Devise is a fantastic gem that handles authentication in rails apps. It also provides token based authentication. You can find many resources on the web (for example here) explainig how to use it. No doubt it will fit for your situation.
i have several questions...
Does yahoo and microsoft api support
oAuth 2.0?
If yes then what are the main
security measures those should be
taken care of while shifting from
oAuth 1.0 to oAuth 2.0.
Google API supports oAuth 2.0. But
they have still marked it as an
experimental. Is it good to start
shifting even though it is
experimental?
I see while registering an
application on google (for oAuth
2.0), they ask for callback url. If a single application uses a
condition dependent callback url
such as -
if($myVar == NULL) $callbackUrl = 'http://www.mydomain.com/test.php?m=f¶ms=null'
else $callbackUrl = 'http://www.mydomain.com/test.php?m=x¶ms=1'
How can i implement above when the callback url is already specified? The above conditional mainly handles fallback model of an application or if browser supports java then java based model of an application. Kindly suggest
May i know how many of email
providing websites and social
networks supports oAuth 2.0?
Yahoo does not support OAuth2 yet, only Oauth 1.
Microsoft does support OAuth2. http://msdn.microsoft.com/en-us/library/hh243647.aspx
Oauth 2 is simpler since it uses SSL (HTTPS) to provide transport security, so the signatures and token-secrets are not needed. When you switch you will need to re-implement your OAuth flow. I can't think of any specific security measures specifically applicable to upgrading from OAuth1 to OAuth2, but the spec details some security considerations in section 10 (The parts applicable to clients are 10.3, 10.4, 10.5, 10.6, 10.8 and 10.9).
The OAuth2 specification is still not finalized, and may change. You could begin to implement your OAuth2 flow with Google, but bear in mind that it is possible that names or requirements of parameters, endpoints etc. could change and your application will break / you will need to make changes in future. [Experimental Features] could change (or even be removed) at any time. It is probably a bad idea to use experimental (or beta) software in a critical production environment.
Also, not all Google services support OAuth2 at the moment. eg. If you want to use OAuth for IMAP access to Gmail you will have to use OAuth1 for now.
In the API Console, you can specify multiple callback URLs for your OAuth2 application, one per line. An alternative would be to store your 'm' and 'params' parameters in a browser session / cookie and do the redirect to the correct page once authorization is complete.
Support (some revision of) OAuth2: Facebook, Microsoft/Live, Google (with exceptions described above), Foursquare, GitHub, Gowalla, GeoLoqi, Salesforce.
Support OAuth1 Only: Yahoo, Flickr, Twitter.
Source.
I am in the process of re-writing some very outdated .NET 2.0 SOAP web services for my company. So I am rewriting them using MVC3 RESTful. This method would simplify the usage of our services for our client base (over 500 clients using our current SOAP services) who are on multiple platforms and languages.
I am looking for a BETTER method of authorization for the RESTful services, than what the previous developer used for our .NET 2.0 SOAP web services (he basically just had the client pass in a GUID as a parameter and matched it in code behind).
I have looked into oAuth and I want to use it, HOWEVER, I have been told, from my superiors, that this method is TOO complicated for the "level" of clients that connect to our services and want me to find another simpler way for them to connect but still have authorization. Most of our clients have BASIC to no knowledge of programming (either we helped them get their connection setup OR they hired some kid to do it for them). This is another reason that the superiors want a different method, because we can't have all 500+ (plus 5-10 new clients a day) asking for help on how to implement oAuth.
So, is there another way to secure the MVC3 services other than passing a preset GUID?
I have looked into using Windows Authentication on the services site, but is this really logical for 500+ clients to use?
Is there an easy and secure method of authorizing multiple users on multiple platforms to use the MVC3 RESTful services that a end-client can implement very easily?
Thanks.
If you don't want anything too complicated, have a look at Basic HTTP Authentication. If you use it over SSL then it should be safe enough and also easy enough to implement for your clients. The Twitter API actually used this up until a few months ago when they switched to OAuth.
You want to distinguish between authentication and authorization. What you are looking for is authentication and indeed as Caps suggests, the easiest way may be to use HTTP BASIC authentication along with SSL to make the password is not compromised.
You could look into other means of authentication e.g. DIGEST or more advanced using ADFS or SAML (ADFS could be compelling since you're in .NET). Have a look at OpenID Connect too - it is strongly supported by Google and has great support.
Once you are done with that, you may want to consider authorization - if you need it that is - to control what a given client can do on a given resource / item / record. For that you can use claims-based authorization as provided in the .NET framework or if you need finer-grained authorization, look into XACML.
OAuth wouldn't really solve your issue since OAuth is about delegation of authorization i.e. I let Twitter write to my Facebook account on my behalf.
HTH