Use Okta (Instead of Local Storage) to Store Your User’s Data Securely
Using an Okta Developer account will allow you to store your cryptocurrency holdings as custom profile attributes instead of using local storage. While LocalStorage is great for demos, using custom profile attributes will allow you to access your data across different devices.
Scott
Are there lighter weight versions of the Okta Java SDK that don’t have so many privledges around a user. The organization I work for is not going to provide apps a token to use the API since the SDK can update a users password or delete a user. I need something that allows me to get the profile data and update profile data but not have full control like the current SDK offers.
Brian Demers
@disqus_0WLsIxuRL6:disqus valid concern! We are looking into creating a lib to support Okta’s /authn API, which would scope changes to the current user. Until then you can use the API directly: https://developer.okta.com/…
Nuthapol Suppakitjarak
Hello, I am attempting to follow the example here.
When I added the import in pom.xml
<dependency>
<groupid>com.okta.spring</groupid>
<artifactid>okta-spring-boot-starter</artifactid>
<version>${okta.version}</version>
</dependency>
<dependency>
<groupid>com.okta.spring</groupid>
<artifactid>okta-spring-sdk</artifactid>
<version>${okta.version}</version>
</dependency>
I am getting the following issue…
Parameter 1 of constructor in com.okta.spring.sdk.OktaSdkConfig required a bean of type ‘org.springframework.cache.CacheManager’ that could not be found.
- Bean method ‘cacheManager’ not loaded because @ConditionalOnClass did not find required class ‘com.github.benmanes.caffeine.cache.Caffeine’
- Bean method ‘cacheManager’ not loaded because @ConditionalOnClass did not find required class ‘net.sf.ehcache.Cache’
- Bean method ‘cacheManager’ not loaded because @ConditionalOnClass did not find required class 'javax.cache.Caching’
I have the following defined per my application in application.properties
okta.client.token=(My token)
okta.oauth2.issuer=(My URL)
okta.oauth2.clientId=(My clientID)
Do you have any suggestions? Any help would be appreciated.
Brian Demers
Hey Nuthapol,
Can you create an issue over at https://github.com/okta/okt… and we can discuss how to reproduce this? A quick list of the dependencies in your pom might be helpful too. I’ve never seen this, so if you have a project you can share that demonstrates the project, that would be great!
jregist
What are your thoughts about how much data you can store in the custom profile attributes? I would expect that adding 5-10 attributes would have negligible effects on our Okta enterprise implementation. Can you provide any details (or links) about the architecture of the Okta backend that might help us better understand the pros and cons of storing attributes in Okta vs in a separate database application?
Randall Degges
The data gets passed along with the user data – it’s a single HTTP request still. The Okta profile attributes allow you to store up to 1MB of data per user, so as long as you are beneath that limit you’re good to go.
If you’re looking to store anything more complicated than simple key/value data, you’re probably better served using an actual database, as you can do detailed queries, etc. But if you’re looking to just tack some basic info onto a user account (avatar URL, favorite color, etc.) it’s a good solution.
PatrickInBama
I’m having to replace our in-house authentication process with Okta and I’ve tried 6 or 7 different process from Okta-hosted widget to custom self-hosted widgets and I think I have found the right combo but have issues with the sdk. So one of my criteria is token reuse. Customers want to login one time and opening other products of ours should reuse the token. We have 6 or 7 products in our line and today each requires you to login. I did have this working with the Okta-hosted widget but I found a flaw in Okta’s code that is a showstopper so I went back to the self-hosted widget. FYI, the showstopper is a scenario where we have a session monitor that monitors activity and after 30 minutes of no activity signs you out and takes you back to the sign on page. Okta has a flaw where if someone were to go to lunch and the session times out, after 15 minutes of sitting on Okta’s signin page, Okta loses track of the originating app so you get their default 400 error page or if you do login and have a subsequent MFA screen to authenticate with and you sit there for 15 minutes, successful re-signing takes you to the Okta dashboard instead of you app. Our users will flood our CSR with thousands of questions.
Any way, the issue I have now is I used Okta’s basic signin widget which works great, but I think it’s missing features. I don’t have the ability to reuse an existing token…each subsequent tab requires logging back in. Worse though is why I’m writing this reply. You hint at using Okta instead of localstorage, yet Okta uses localstorage to store all tokens. Isn’t that a bad practice? With an access token, any hacker has all they need to hack your application. Yet, none of Okta’s documentation ever mentions how to replace their token storage with something more secure. Their widget will break if you move your storage provider to a custom one. What ideas do you have to help me replace Okta’s default token storage with a custom storage provider that is more secure?