I'm integrating Okta into an iOS app and I need to create a custom new user registration UI. I can't seem to find anything on this in the documentation but this must be a common use case.
Is there an SDK available to help with this (similar to login) or will I have to hit the APIs manually?
You will need a backend application to make a call to Okta to create user if you need a custom registration UI as it requires an API token or access token with high privilege.
You can use one of the management SDK's based on your backend application language.
You can find some links below:
.Net SDK: https://github.com/okta/okta-sdk-dotnet
Java SDK: https://github.com/okta/okta-sdk-java
Hitting this endpoint manually is the solution. Just make sure you're providing an API token, not a user token.
Related
I have the following set up:
A web app (Jetty/Java)
A native client (iOS) (calling my webapp)
The Microsoft Graph API (called from my webapp)
The idea is that the user should sign in with OpenID/Oauth2 using his/her Office 365 credentials. The webapp will then call the Microsoft Graph API on behalf of the user (offline as well).
To achieve this I'm pretty sure I need to use the grant type: "Authorization code grant".
I can find a lot of example of the Oauth2 flow for browser based apps, and for when the native app calls the Graph API directly... but I want my backend to call the Graph API (and hold the access & refresh tokens).
So the question is how to do this properly? Here is my idea at this point.
From the native app: open a browser, call my web server which will trigger a redirect to the Azure /authorize endpoint (example: https://login.microsoftonline.com/[tenant]/oauth2/v2.0/authorize?client_id=[clientid]&response_type=code&scope=offline_access%20user.read%20calendars.readwrite&response_mode=query&state=12345&redirect_uri=my-scheme://oath2-code-reply
This will trigger authentication/authorization and then send the access code back to the app (using a custom scheme redirect: my-scheme://oath2-code-reply).
The app can then call my web app with this access code, where we can exchange the code for refresh & access code, and also create our own session for the user.
Is this the correct way?
Or should the entire flow occur in the browser and as the final step I open the app again with something like myapp-scheme://?sessionid=[our-own-session]?
For your scenario, you should use the on-behalf-of-flow.
A server-side sample that you can use as reference is https://github.com/Azure-Samples/active-directory-dotnet-webapi-onbehalfof - a note is that this sample is a .NET sample using a JavaScript SPA as a client - but hopefully it can guide you. You can use this sample for an overview on how to request tokens for your web api.
A note is that your item '1.' suggests that you are using the 'v2' endpoint. The 'v2' endpoint has some limitations, including for the scenario you are trying to accomplish (request access token to a Web API) - please see this document with information on these limitations, therefore my recommendation is to use the v1 endpoint at this moment for your scenarios -- which mean that you can only authenticate corporate accounts (and not MSA). The documents and samples I've indicated above uses the v1 endpoint.
Not sure if that is possible: I would like to switch from server flow to native client flow in order to provide a better authentication experience for my users.
The problem is that Azure AppService requires a "web application" OAUTH setup (contains client ID and a secret), while the native login works with just a client ID and not secret. This means that after the login on the phone, I do have a Google token, but AppService wouldn't know what to do with it and returns me an HTTP Unauthorized.
The mobile client SDK gives me an API, but that doesn't work with such a token.
var jObject = new JObject(
new JProperty("access_token", auth.AccessToken),
new JProperty("id_token", auth.IdToken));
await ServiceClient.LoginAsync(MobileServiceAuthenticationProvider.Google, jObject);
Any idea on the proper way to integrate this without having to write my own server-side token validation?
You would still need to configure the web application in Google since you are attempting to access a non-Google API. The native login on its own is not enough.
That means you will still need to provide the backend with an ID and secret. The client is responsible for obtaining an id token and authorization code which get sent to the server, and the server does the actual retrieval of the access token, per the Google documentation.
So that means your call will actually look something like the following:
var jObject = new JObject(
new JProperty("authorization_code", auth.ServerAuthCode), // not sure what property your auth binding exposes this as
new JProperty("id_token", auth.IdToken));
await ServiceClient.LoginAsync(MobileServiceAuthenticationProvider.Google, jObject);
There isn't documentation for the end-to-end using Xamarin.Android, but you might find it useful to glance over the App Service iOS documentation for this scenario just to see the moving parts. The general pattern you will follow is:
Configure everything for the server flow (as you've done before)
Set up the Google Sign-in SDK (seems like you've done that already, too).
Make the call as described above
The main issue you might run into is making sure that you have the API console registration correct. You'll want to make sure you have an Android client there connected to the web application client ID you are using. I'd recommend giving the Google Sign-in for Android setup instructions a quick look. Also note that authorization codes are one-time use, and there are some throttles that Google puts in place for a user requesting too many of them within some span of time. You might run into that during dev.
AS far as I know, the native client flow also use the google code flow to get access token.
According to this article, the Android, iOS, or Chrome applications doesn't need the secret to get the access token.
The client secret obtained from the API Console. This value is not needed for clients registered as Android, iOS, or Chrome applications.
But the web app backend will not authorized this access token if you don't set in your backend to enable Azure App Service authentication/authorization. Because the backend will have its own logic(the mobile server library write the logic according to the access token) to return the auth token according to the access token.
Now, the most easily way to enable the client flow in your mobile app is set in your backend to enable Azure App Service google authentication/authorization with the same clientid and secret(based on my test: if you don't set the right secret, the backend will still return the auth token).
Here is the test image:
If you still don't want to enable the app google easy auth, I suggest you could create custom authentication which contains your own logic to check the accesstoekn and get the user information from the google.
If the checked result is success and get the enough value, you could generate the auth token and return to the client side.
More details about how to create custom authentication in the mobile app backend , you could refer to this article.
My question is quite simple, if you want to integrate social media oauth 2.0 you have to add the callbacks to an application for that specific social media platform such as FB/LinkedIn. Afaik, there's no way to add these callbacks through an API of some sort, correct? Meaning that if I want to add say a 100 callback links to fb, I'd have to add them manually?
To my knowledge, you're correct; it would be a manual process. There are a few specifications that would allow a more programmatic control of this registration information, but the specific provider you wanted to use would have to support them or a custom approach and again I don't think Facebook does it. For reference purposes:
OAuth 2.0 Dynamic Client Registration Protocol
OAuth 2.0 Dynamic Client Registration Management Protocol
Another possibility would be to go through a mediator that integrates with the providers you need to support and that can act as a provider on his own and at the same time allows you to configure the redirects in a programmatic way.
Diclosure: I'm an Auth0 engineer.
An example of this, would be Auth0; it integrates with Facebook and LinkedIn, but then allows your custom application to talk directly with Auth0. The benefit is that you configure Facebook and LinkedIn integration once with a single redirect URL and then can use that configuration acroos multiple applications.
Since Auth0 exposes OAuth2/OIDC endpoints you would still talk the same protocols but could now leverage Auth0 Management API to perform programmatic administration of the OAuth2 client application registration information; including the dynamic registration of redirect URL's. If you use FB or LinkedIn purely from an authentication standpoint this is a real straightforward approach to achieve your requirements. If your required the access tokens from FB to then make calls to their API on behalf of the user, although still possible with Auth0, you have a bit of overhead as these tokens would not be automatically available to your custom applications.
For my current work project we're trying to use OAuth to secure a mobile API, but the app doesn't have user accounts, so authentication would take place invisibly from the user, where the app will send up some secrets to the server and receive the token to be used for subsequent web service calls. The problem is, all the libraries and tutorials I can find implementing OAuth follow this pattern:
Present a web view allowing a user to login
Receive a callback to a custom URL scheme, and parse the necessary information to authenticate future web service calls
How do I achieve this without the webview step? I should be able to make an HTTP request directly with the correct credentials which will return the necessary authentication details.
The app will use OAuth 2.0
It is not clear what do you mean by
the app doesn't have user accounts
If you want to call some API on behalf of user you should ask him for a password. Doing it in webview or not depends on provider implementation. For example, twitter doesn't force you to do that.
In other case, if you want to call service on behalf of client, take a look at this answer: https://stackoverflow.com/a/7477112/2283405
If the app doesn't require "personalised" or "user-specific" data to be manipulated, then you can probably try using "client-credentials" grant type to obtain access tokens using the application credentials granted upon the application registration process by the Authorisation Server (for e.g.: OAuth server) that's there in your environment. The idea is that, your app is what basically authenticates with the Authentication Server for you using the aforesaid credentials (i.e. Client Consumer Key and Client Secret Key).
NO, you have to do login compalsary. if you try without. it won't be possible.
I'm developing an iOS app that uses the Magento REST API, I'm following the documentation provided by Magento for the OAuth authentication (http://www.magentocommerce.com/api/rest/authentication/oauth_authentication.html)
I use the initiate endpoint to get the request token but then when I want to authorize this token I need to use the "authorize" endpoint and there I get redirected to a URL where I have to provide customer credentials to authorize the request token. This is not the behaviour that I was expecting since the user would be already logged in using the app's login (not implemented yet). Is there a way of making this "authorization" step transparent for the user? Like calling some service passing it the user's credentials provided in the login screen of my app?
If there is no way I'll use the Magento's SOAP API
I did that too really really painful Magento use OAuth1.x, basically you've got three options:
Do it yourself
Use some oAuth consumer lib, you can find them on github
Use MKNetworkKit with this add-on
I used the 3rd because oaf MKNetworkKit, and anyway there was still a lot of work to do, if you want to hide some passages injecting js.