I am currently implementing an SSO-OBO flow for my addin. In this flow, I basically request for a bootstrap token from the Azure Identity platform using the Office.Auth.getAccessToken() API. And then exchange that for a Microsoft GRAPH token using the auth-code flow. And it works correctly.
This entire process of getting the Bootstrap token, and exchanging it for a Microsoft GRAPH token takes around 2.52 seconds. (Average time over 10 trials.)
I have 2 questions related to this :
Is 2.52 seconds normal for this type of transaction?
If it is not normal, are there any documents or techniques that can help me increase the speed of this 'exchange'?
Please note that I used a free account AWS-Lambda/API Gateway for the tests I executed. I am not so sure if that affects latency. Also the test was done using a 50mbps connection.
Thank you all in advance.
I have similar numbers (a bit faster though, ~800ms. Probably it's related to the azure datacenter location vs your app location). The bandwidth does not matter, as the amount of data transferred is tiny, but ping does (I'd at least make sure that your AWS app and Azure datacenter you are making request to, are located in the same country / part of the world)
You can cache the token (in the local storage, for example) and use the cached copy until it expires. The expiration time is written in the token itself ("exp" field, you can look at the contents of the token using the https://jwt.io for example). Or you could use some library that would do caching for you.
Related
I am trying to configure a mailbox on Exchange Online to be used by our Deskpro ticketing system to manage several queues. The only way I could setup Deskpro to recognise different folders in the mailbox was to make the connection using EWS. MS said they would be deprecating EWS Basic Auth in October last year, does that mean my EWS connection via outlook.office365.com/EWS/Exchange.asmx is now authenticating through OAuth? It still works, I'm concerned MS will change something and it'll stop working.
I'd love to use the OAuth via Graph, but if I select that option in the Deskpro setup there's no way to identify individual folders for each queue to process meaning I'd have to have a separate mailbox for each queue requiring an Exchange Plan license for each!
Collin, yes there is an announcement made to deprecate EWS Basic auth (it was made quite some time earlier too) and move to modern auth/oAuth too - it will work for you. Also you know that no new investments are going to be made in EWS, so you wont get any new features. So keeping in that mind, you can use EWS modern auth/oAuth for a while, but i would recommend you to create plan to move to Microsoft Graph API - so that you can interact with all the existing features in EWS and connect with entire Microsoft Graph ecosystem's product/solutions as well.
I'm trying to use delta queries on my AD and it works perfectly when I try them out through Graph Explorer, but doesn't work at all with my app, I'm getting this:
message=Invalid request. Delta query is not supported by this resource.
My app is an 'old' app, meaning it was registered in Azure to work with old WAAD graph api. Is this why it's not working? Or could this be because of my app lacking some permission that Graph Explorer requires? I can read 'users' without any issues, it's only delta queries I'm having issues with.
The application requests the following permissions:
Access the directory as the signed-in user
Read all users' basic profiles
Sign in and read user profile
Token requests are managed by the library, it's asking for the following scopes: openid profile
If you're using Azure AD Graph then you cannot use /delta queries. AAD Graph API and Microsoft Graph API are entirely distinct APIs. Calls to one are not interchangeable with the other.
If you're looking to leverage /delta you'll have to refactor your application to use Microsoft Graph API.
Had to spend the whole day on this issue, here's what was going on. I was adding this HTTP header to the request (per some sample documentation):
Prefer: outlook.timezone="E. Europe Standard Time"
And that's what was breaking the delta queries request, as soon as I've removed the header - request returned delta data instead of an error. I wish the error could be more descriptive, I wouldn't have to spend so much time figuring this out.
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
I'm working with a company that's implementing OAuth, and currently they're supplying an access_token with a lifetime of 180 seconds. This seems short to me, so I'm trying to figure out what a typical lifetime for an access_token is, from what other companies do on the web.
I've seen on the web that:
Twitter lets them live forever
Facebook expires them after ~60 days
So it seems to me that 180 seconds is way too short, as it will force developers to constantly have to use the refresh_token to request a new access_token.
Any suggestions?
EDIT: At first I was asking "What's a reasonable life time for an OAuth access_token?". I've changed the question to "What's a typical life time for an OAuth access_token?", as I think this is closer to what I actually meant.
Short answer:
What is reasonable all depends on the company policy and its OAuth implementation.
Long Answer:
The access token lifetime is really up to the supplier of the token i.e. the Authorization Server of your partner company and its policy.
I would agree that 3 minutes is very short but the company's security policy may demand that on revocation of certain permissions or account removal, access for clients who were granted access based on those permissions is disabled within no more than 3 minutes. The fact that this comes at the cost of quite significant network and processing overhead is something that is calculated in (hopefully).
The cost (as in: overhead) of that decision also depends on the usage of the token itself. It it is used infrequently but always in burst mode, the overhead may be relatively low. If it is used frequently but just for one API call each time, then the overhead is relatively large and thus the cost higher.
Most environments wouldn't require immediate removal of all delegated access on the spot and would find it affordable to deal with a delay of at least 1 hour.
On the other hand, Twitter and Facebook are implementing OAuth in such a way that they can afford long-lived access tokens: when the Resource Server receives an access token, the permissions associated with the account that issued the token are checked. Of course for performance reasons the Resource Server will cache those results (for the sake of the discussion, say for a duration of 3 minutes) but effectively it yields the same result, pushing the "refresh overhead" to the Resource Server instead of the Client. (Note that this somewhat defeats the purpose of using structured self-contained access tokens such as JWTs).
The approach of Twitter and Facebook works if you don't need/want to explicitly authenticate your clients again within reasonable bounds. Since Twitter and Facebook also don't authenticate their users very often, that approach make sense for them.
I guess you could say that each use case is different: it all depends on what you want and how you implement it. And your company and Facebook may not be comparable because they have different tokens, Resource Server implementations and restrictions on client (and user) authentication.
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.