Can I do incremental Permissions with the msgraph-sdk-javascript library? For example, a user signs in only with the profile but later authorizes access to to their email account or calendar.
As you can see here, the Microsoft Graph JavaSciprt SDK doesn't include an authentication library. It is only a higher level wrapper for calls and serialization of objects.
It is your responsibility to obtain an access token and provide it to the library. You can pass in a token this way:
var client = MicrosoftGraph.Client.init({
authProvider: done => {
//first parameter takes an error if you can't get an access token
done(null, "PassInAccessTokenHere");
}
});
Microsoft is going through an important transformation for the authentication and authorization endpoints (v1 vs v2). One of the major differences is that v2 supports scopes (as opposed to resources in v1) which provides support for incremental consent.
Microsoft currently maintains two authentication libraries:
Adal.js which targets the v1 endpoint (and doesn't support incremental consent)
MSAL.js which targets the v2 endpoint (and support incremental consent)
Lastly, v2 has a set of limitations in terms of supported flows as well as supported APIs.
I recommend you read a lot on the subject before making a choice to make sure you won't end up in a dead end of "something is missing in that version" in the middle of the project.
Related
I am a bit confused about the difference between OData and OAuth? Are they both protocols for authorization? Or they are used together?
Thay are totally different things:
OData
is a protocol for querying an endpoint and service information.
You are able to perform select and filters against it.
OData (Open Data Protocol) is an ISO/IEC approved, OASIS standard that defines a set of best practices for building and consuming REST APIs. It enables creation of REST-based services which allow resources identified using Uniform Resource Locators (URLs) and defined in a data model, to be published and edited by Web clients using simple HTTP messages.
The formal documentation is a bit broad, but I believe the examples are pretty interesting, note the filter parameter:
https://example.org/Airports?$filter=contains(Location/Address, 'San Francisco')
See source tutorial.
OAuth
is a protocol for authorization.
OAuth 2.0 is the industry-standard protocol for authorization. OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices. This specification and its extensions are being developed within the IETF OAuth Working Group.
OpenIDC
OpenIDC is an OpenID based authentication standard on top of OAuth.
I think it's worth to mention because this often is mentioned together with OAuth.
OpenID Connect is a simple identity layer on top of the OAuth 2.0 protocol, which allows computing clients to verify the identity of an end-user based on the authentication performed by an authorization server, as well as to obtain basic profile information about the end-user in an interoperable and REST-like manner.
I am currently using the old Outlook office REST API v2 to access outlook.com mail of users via oauth (as opposed to microsoft graph, due to a lack of certain desired features)
For authentication scopes, it needs values like
https://outlook.office.com/mail.readwrite
https://outlook.office.com/mail.readwrite.shared
vs microsoft graph's
Mail.ReadWrite
Mail.ReadWrite.Shared
Unfortunately, the documentation that supposedly provides a comprehensive list of supported scopes https://dev.outlook.com/restapi/getstarted has had its links changed to point to microsoft graph's documentation (which doesnt really help at all)
THE FOLLOWING IS FROM THE ABOVE LINK, AND REDIRECTS TO THE BELOW LINK
scope: a space-delimited list of access scopes that your app requires. For a full list of Outlook scopes, see Authenticate Office APIs using the "v2.0" endpoints [https://developer.microsoft.com/en-us/graph/docs/authorization/auth_overview]
I'm not aware of a global list of Outlook scopes but they should be documented along side each REST method under the Minimum Requires Scopes.
I'm trying to obtain an Google OAuth 2.0 access token for a service account but receive an invalid_grant error instead. I've checked my various artifacts (private key, etc.) and clock timings but have not been able to resolve this so far.
There is one possibly related item that seems odd: Google's documentation says
Three parameters are required in the HTTPs POST, and these are shown
below
This is followed by a table with two rows that specifies two parameters (grant_type and assertion). Could it be that a third is also needed (I've seen examples that also use assertion_type in some fashion)? Could it be that (some) Google engineers (or perhaps yours truly) cannot count up to three? :)
In summary: What are the appropriate parameters? It seems unclear from Google's current documentation.
UPDATE: Here is some further information: I can't use the Google API Client Library, because my application requires a language other than those currently not supported by Google. Therefore I have to implement the logic for creating and signing JWTs, etc., as is normally discouraged. I have confirmed that my service account artifacts are in order: I can use them with the Google APIs Client Library for Java to access the same calendar (from another than my target platform, i.e.). In particular, my "client_id" is of the form "...#developer.gserviceaccount.com" and my key is a 128-bit RSA private key, both as obtained from the Google APIs Dashboard.
I've now been able to confirm that it's two parameters, not three. Google's documentation seems to be correct insofar as it names those two parameters (grant_type and assertion) but wrong insofar as it refers to them as three parameters.
Evidence for two parameters comes from a current Internet-Draft (JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0), which defines an extension grant type under RFC 6749 (The OAuth 2.0 Authorization Framework).
Evidence also consists of having tried a verbatim access token obtained by the Google APIs client library (and revealed by logging) inside my (non-Java) implementation: use of this access token has made the invalid_grant error go away.
(There now evidently a problem about forming a SHA256withRSA signature left in my code, but that's another issue ...)
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.
What is the difference between Claims based authentication vs What is provided by OAuth.
I am looking for conceptual difference and not technical difference. When do I choose Claims over OAuth and vice versa.
Claims based authentication is proposed by Microsoft and build on top of WS-Security. But OAuth is more a open source protocol that is being proposed to allow fetching resources from different portals based on a security token.
Claims also has this concept of token (SAML encoded or X509 certificates).
I am trying to understand when do I choose Claims over OAuth and vice versa.
Thanks
Claims-based identity is a way of decoupling your application code from the specifics of identity protocols (such as SAML, Kerberos, WS-Security, etc). It is not only for web applications and is implemented as a .NET library / framework called WIF.
OAuth is a specific protocol by which one web site can obtain user consent to access their private data on another web site.
It is not really the case that you would choose one or the other, in fact they are complementary. Potentially you could use both at once, if you were building a .NET web app that performed OAuth via the WIF.