ADFS, iOS, and certificates - microsoft-graph-api

I'm using the MSAL framework in an iOS app. It's all works well when I authenticate against our inside ADFS server that only needs username/password. The public facing server requires a client certificate. From the public Internet, when I hit the Graph API without a token, I get redirected to a page that says a certificate is required and to select one to use. There is nothing to select and I can't do anything other than exit at that point. I see the same behavior with MacOS and Safari. Am I missing something or should this work?

Related

Generating Credentials Auth Error - redirect_uri

I'm receiving an Authorization error when attempting to generate an authorization code:
Error 400: invalid_request
You can't sign in to this app because it doesn't comply with Google's
OAuth 2.0 policy for keeping apps secure.
If you’re the app developer, make sure that these request details
comply with Google policies. redirect_uri: urn:ietf:wg:oauth:2.0:oob
I've used this Google tutorial to replicate and confirm the issue:
https://developers.google.com/assistant/sdk/guides/service/python/embed/install-sample?hl=en_US
It is generating this URL:
https://accounts.google.com/o/oauth2/auth?response_type=code&client_id=[HIDDEN]&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob&scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fassistant-sdk-prototype&state=[HIDDEN]&prompt=consent&access_type=offline
Here is a workaround provided by jdtoth on Github: https://github.com/greghesp/assistant-relay/issues/266#issuecomment-1065940698
Thanks jdtoth!
I found a workaround for creating a new user. In my case, I needed to
create a specific type of API credential. Here is what I did:
Create a new OAuth Client credential using the link below, ensuring
the application type is "Web application" and set Authorized Redirect
URIs to "http://localhost"
https://console.cloud.google.com/apis/credentials
Download the key, and create the user in the Assistant Relay appas you
tried before. When it opens a new browser window to authorize the
google account, you might need to bypass a warning. After you do this,
a blank browser window will open but the address bar will contain the
auth code you need. Grab the code from the relevant part of the URL
here and paste it back into the Assistant Relay app:
http://localhost/?code=COPYCODEFROMHERE&scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fassistant-sdk-prototype
Let me know if this works. I am successfully sending commands to the
Assistant Relay server but nothing is playing on my speakers.

Thinktecture Authorization Server TokenRequestValidator returns 'Anonymous Client'

I have an interesting problem. We have set up the Thinktecture Authorization Server from the trusty Identity Server 2 and gotten it to work a few months back. It is configured as a relying party for an already existing corporate identity server, so when we use the Code Flow example, click the "Start authorization handshake" we bounce over to the identity server, supply our credentials and get bounced back to the callback of the code flow with an access code, click the Get Token, and are granted with this fine jwt token. All seems fine.
However,
When we try this either from, for instance, postman, or our app development team from their development devices (android and iphone), it starts fine but when we call the token endpoint with our newly minted access code we get an "Anonymous client" response.
Looking at the web example from the CodeFlow example I see it posts basic authentication including a base64 value of the secret wich is missing from postman and our app team. I see no reference to this in the CodeFlow example so I have no idea where this comes from. If I hard code the Authorization BASIC [including the Base64 secret I snatched from the previous example] it does not change anything.
We'be been stuck for several days on this so any help would be gratefully appreciated. Any Ideas?
After a lot of recearch and hair pulling it seems the Postman client we are using does not support Code Flow and therefore does not include the Authorisation header we are missing. After capturing the traffic from Postman with Fiddler we manually added the basic authorization header with the client name and secret and got everything working. So as of now, postman does not work.
I hope postman does add support for codeflow in the future.
Atli

Outlook 365 OAuth login fails with Error in OAuth Server: temporarily_unavailable

My company develops a web app that requires 3rd party authentication with Outlook 365, to have access mail, calendar and contacts.
We managed to get several users from various tenancies connected through OAuth using the normal OAuth flow and the endpoints:
https://login.microsoftonline.com/common/oauth2/authorize
https://login.microsoftonline.com/common/oauth2/token
But one user constantly fails at login with the error:
{
"line":"398",
"file":"oauth_server.js",
"message":"Error in OAuth Server: temporarily_unavailable",
"time":{"$date":1436988123251},
"level":"warn"
}
It only happens for his tenancy, and only on our production servers (he can successfully connect with our test servers).
All the settings are analogous for the production app and the test app in the AzureAd portal.
This error states that the microsoft servers are unavailable, yet they manage to connect any other account, which tends to prove that this message is inacurate...
Would anyone have a clue about this?
This solved my problem:
I went to the AzureAd management portal,
went to the configuration page of my app,
changed the APP ID URI to something random
saved,
tried to connect with this account, successfully!
set back the APP ID URI to its original value.
Still works. I do not know why. Something must have been stuck in the pipe...

Google+ SignIn Hybrid Approach IOS/Python REST Server

We are trying to incorporate the Google+ SignIn button for authentication to our IOS client and python tornado REST Server.
On the IOS client, we followed the "Enable server-side API access for your app" in https://developers.google.com/+/mobile/ios/sign-in. We set the clientID to the Google+ IOS Client and the homeServerClientID to our web server Google+ Web client id.
Then on our tornado werver, we used the python google+ client and did:
oauth_flow = flow_from_clientsecrets(GOOGLE_CLIENT_SECRET, scope='email')
oauth_flow.redirect_uri = 'postmessage'
credentials = oauth_flow.step2_exchange(code)
So the IOS client works fine, it authenticates, gets the one time token in homeServerAuthorizationCode. It sends this to the REST API and it produces an exception:
File "/usr/lib/python2.6/site-packages/oauth2client/client.py", line 1964, in step2_exchange
raise FlowExchangeError(error_msg)
FlowExchangeError: redirect_uri_mismatch
We have tried to use difference codes, double and triple checked the client ids in the clientsecrets, IOS and tornado code and they are all correct.
Any ideas?
It is likely that it's not happy with the redirect URI on the server side. 'postmessage' is absolutely right for the web flow, but for iOS try either not specifying redirect_uri at all, or using 'urn:ietf:wg:oauth:2.0:oob' (oob being "out of browser") for the redirect_uri.

How to secure my api using node.js and only my app is using this api

I want to create a iOS app, and I am starting to design a api using node.js+mongodb+express. I know people can use charles to set up a proxy and when user open the app in the iphone device, they can see the api requests in charles app. So people can use this api to do some harm to the app services or what. I want to secure my api. I won't open my api to others. So, I don't need oauth. What else I can do to secure my api? And if any tutorial is provided, that will be good.
Do it with https, just make sure your app stops working if the certificate is invalid.
Alternative:
Crypt/decrypt your http(s)-body before sending/after receiving with a global password (not recommended) or a public key on your phone and a private key on your application.
If someone gets that pw or public key, they can still manipulate the API.
What you want to do is use https with additional security.
First: In the app "pin" the server certificate, that is validate the server certificate in the app, this is quite common these days. AFNetworking supports this.
Second: Add a certificate to the app and verify it on the server. Now the server knows it is communication with your app.
Now both the server and app have assurance they are communication with authenticated end points.

Resources