The downside is that Okta pricing (https://www.okta.com/pricing/) appears to be per User, instead of usage based (per API call) the way Stormpath is. This will make a migration much tougher. Auth0 appears to have better pricing imho (https://auth0.com/pricing).
Alex (Stormpath CEO) here - we're working on self-service developer pricing for Okta. We're announcing the news before pricing was baked so our customers and users could have as much transparency as we could offer, as early as we could offer it.
I'm a big believer in clear, transparent pricing that works for all customers. Please stay tuned.
Thanks Alex, I appreciate that. Is it your plan to launch self-service pricing prior to the API shutdown at Stormpath? I'm hoping yes so that it is as painless as possible.
Yes. It's currently my highest priority and we're making good progress. It won't be perfect of course but it will be a good first start. I don't have a date for you, though, but our goal is ASAP.
Congrats to both teams. As a side note, last summer my startup joined Angelpad's accelerator program.. during that time I reached out to @alexsalazar with a laundry list of questions about B2D sales strategy and how he was thinking about the difference and similarities to a traditional b2b sales team structure. He was incredibly supportive and willing to share knowledge and his experience! Thanks again Alex!
FAQ also says you will need to export your data from SP and, presumably, manually import it in to Okta. If thats the case its going to be hard to do it without end user disruption.
Heyo! I work on this process @ Stormpath / Okta. It will largely be an automated process in two stages: export then import. You'll be able to do multiple exports / imports, so you can continue running in production on Stormpath while testing on Okta.
The flow is pretty simple: export your Stormpath data (no interruption), import to Okta, test, then when you're ready to go 'live': export from Stormpath again and pause servers, import to Okta again (to get new things added), and switch code to run against Okta.
I was not please when I saw the answer to this FAQ question:
Can I use a Stormpath SDKs (like Java, C#, and Node.js) with Okta?
We are not migrating the Stormpath SDKs to work with the Okta API. Together with the Okta team, we will develop robust, new SDKs for the Okta API, but these may not be available before Stormpath is shut down. Okta has a REST API that provides functionality similar to the Stormpath API. This can be used in the interim while new Okta SDKs are being developed.
It doesn't make any sense not to have the SDKs available long before the shutdown date.
While we are not porting the SDKs, we are targeting end of April for framework integrations, so most Stormpath users can migrate with a pretty simple version upgrade. Most users are working with these and not our base SDKs. We are prioritizing:
Java Spring
Java Spring Boot
Node Express
ASP.NET 4.x
ASP.NET Core
Passport (https://www.inversoft.com/products/identity-user-management) provides an on-premise option as well as a private-cloud solution (single tenant). This helps you protect your data but also prevent issues like the API being shut-down.
18 comments
[ 4.5 ms ] story [ 58.5 ms ] threadI'm a big believer in clear, transparent pricing that works for all customers. Please stay tuned.
FAQ also says you will need to export your data from SP and, presumably, manually import it in to Okta. If thats the case its going to be hard to do it without end user disruption.
The flow is pretty simple: export your Stormpath data (no interruption), import to Okta, test, then when you're ready to go 'live': export from Stormpath again and pause servers, import to Okta again (to get new things added), and switch code to run against Okta.
We'll be releasing more details soon.