I'm working on an ionic app which start with a login system, I already create a basic authentication system which fetch in the database for the username and the password if exist I get as output the ID of the user and his full name and I store them in the local storage but I can see that this way isn't secure enough so how I can build a strong and a secure authentication system using ionic 4v, I found something like using a token and store but i didn't get the idea
Note : for the Backend there is an other team works on it they use JEE with SpringBoot Framework
I would suggest going with the JSON Web Token (JWT) approach. You can find more information on it here. You basically want to create an API endpoint that consumes the users username and password then validates it and if it is successful it returns a JWT.
JSON Web Token (JWT) is an open standard (RFC 7519) that defines a
compact and self-contained way for securely transmitting information
between parties as a JSON object. This information can be verified and
trusted because it is digitally signed. JWTs can be signed using a
secret (with the HMAC algorithm) or a public/private key pair using
RSA or ECDSA.
You might also want to include refresh tokens so that you can get a new JWT when the current one expires as putting a long expiry on a JWT is not recommended.
You will need to provide more information on what programming language your backend/API is in so that we can assist you with the correct implementation thereof.
I am creating an application which is like a template where every service provide can enter their details in the setting on the web and just change the app name ,app icon, new bundle identifier and upload the app on app store.
Till here it was good, But the problem for me is that I have a push notification services in this app.
And I have read on the apple document that every bundle identifier should contain a unique push certificate. And from there we create a .pem file, so that means every app will have a different- different pem file.
But I want a single pem file which will work for all app.
Can anybody please suggest me what should I do, or what is the proper way to go about it?
Unfortunately, what you are asking for is not currently possible with Apple Push Notifications Service. Though you could conceptually use several of the optional arguments in openssl to generate a Certificate Signing Request (CSR) using the exact same keypair, the root issue comes from the 'Certificates, Identifiers, and Profiles' tool in the very first step in creating a new APNS certificate:
As the supplemental instructional text reads: "Note that only explicit App IDs with a specific Bundle Identifier can be used to create an [sic] Push SSL Certificate", which means that we can neither provision a Wildcard App ID for push notifications, nor can we specify 'All App IDs'.
If we briefly step into a hypothetical world where the "Which App ID would you like to use?" question doesn't exist and instead went directly to the step where we upload our CSR, the certificate we would get back from Apple would do exactly what you want -- It would authenticate the server you use to construct APNS payloads as one legitimately belonging to you and authorized to send pushes to the APNS Gateway. It does, however, open an important security concern -- If you can use this one server (or 'provider' in APNS parlance) to send pushes to any of your apps (so long as you know the device's APNS token), what prevents you from using your provider to send pushes to my apps? Or if we turn the concern around -- what would prevent me from using my authorized APNS provider to send your apps push notifications? Or to send pushes to your customers with misinformation (ex. 'Regrettably MyApp is closing its doors and exiting the App Store. MyApp recommends customers purchase CompetitorApp to maintain your service!'). This slimy, scam-prone world we thankfully don't live in...
Instead, Apple requires 3rd-party developers to select the AppId for which payloads from a particular APNS certificate will be honored. Then even if I somehow manage to acquire your customer's app's device token, I won't have your server's private key and thus could not successfully deliver a scam, spam, or otherwise rogue APNS payload to your customers.
Ok, I got it already! Since I can't use a single certificate for multiple App IDs, what can I do?
Given some of the background in your question, it sounds like you've put in the effort to make your app highly configurable. In your own words "[it] is like a template" - which would suggest that on the server-side of your app, you have some mechanism in place to be able to be able to identify what app is making data requests and which provider's data to send back. Your APNS Provider logic would need to have similar intelligence built in. Depending on how you are currently making these server-side distinctions, you may be able to reuse some of the existing logic; you are the one who will have to make that call. The remainder of this answer will offer a high-level approach to how you might choose to setup your provider owing to the one-pem-per-app requirement APNS imposes. In general:
Place a copy of the signed .pem in a secure location on your APNS Provider
Update your Provider's 'register device token' API to accept both the device token as well as some way to uniquely identify the app for which this token is valid (...maybe as simple as just the App ID itself!)
Update the iOS App to pass both it's APNS device token and that App Identifier to the freshly updated 'register device token' API on your provider.
Update your Provider's logic to use the correct .pem when delivering a payload to the APNS Gateway.
For the sake of good process, ensure that you have a procedure to update or retire an application's .pem, data, and relevant tokens.
For each app that you make from your template, you already have to generate a unique App ID and App Store Distribution provisioning profile. When doing this initial setup, you can also request the APNS certificate and treat all three pieces of data as app-specific settings. Install the APNS certificate into your provider along side the .pem file for your other apps so that you can grab it when it comes time to send an APNS payload to Apple.
If you've done APNS work before, you know that your provider is responsible for tracking app-specific device push tokens, generating and transmitting the APNS payload to Apple, and optionally using information from the APNS Feedback API. When your app connects to your provider to register its token, you'll also need to know for which app that token is valid so that you can select the right .pem for sending APNS payloads. This is key; if you don't have a way to know which tokens go with which App IDs then you will be unable to select the right .pem file during payload generation and dispatch.
Updating and retiring software is a key part of all software, but is one that doesn't always get the attention it should. Make sure you've considered how you'd go about refreshing the .pem file (which you'll have to do each year before the current one expires) as well as how you'd go about retiring an application without disrupting the other apps your provider services.
The answers to each of these questions is very much dependent on how you've architected the various components of your app, Xcode project configurations, server-side technologies, and server-side logic. Only you, or your team, can make the right call based on the details that make up your software. Best of luck and let us know how things go.
We are currently trying to create our own system, where users can create user accounts using their iPhone. However, we're not sure how we can securely create accounts for users with their own password set and everything. I've been told this is only possible with HTTP requests, which doesn't really look safe.
You can always encrypt the data you send via http
See answer to this question for the link to the tutorial:
AES 128 Encryption for iPhone HTTP Stream
I'm adding rest API for mobile application into my existing grails web app. Since I'm having hard time with integrating OAuth2 provider into my application, I'm going to implement my own HMAC mechanism.
HMAC uses secret key and what I want is, that each user of application has it's own secret key. Now the thing is how do I transfer secret in a safe manner between API and mobile device initially.
Of course all communication will be through t SSL. But is it safe to send client secret from server to mobile client when connecting for the first time over the wire?
Or I should use one secret and store it with mobile client, which could be easily reverse-engineered?
Or maybe there are other and better ways to do it?
You may want to look into shared key authentication schemes and implement custom mechanism.
Here is example how Amazon use it for REST request:
http://docs.aws.amazon.com/AWSECommerceService/latest/DG/Query_QueryAuth.html
and sample java code
http://docs.aws.amazon.com/AWSECommerceService/latest/DG/AuthJavaSampleSig2.html
I am interested in playing HTTP live streaming data from my app. The stream (which I create) is encrypted, and a URL pointing to the AES key is included in the stream index file.
MPMoviePlayer hits this URL for the AES key, when it sees that encryption is enabled.
I would like this URL to be served by https, and for MMMoviePlayer to use a client certificate that I provide when the user purchases the content. I also do not want any user interaction for authentication, since they have already agreed to purchase the certificate.
Can I programmatically install the client certificate from my app so that MMMoviePlayer transparently uses this certificate to authenticate when getting the AES key?
Thanks!
Yes you can, check out the CredentialImportController class in this sample code http://developer.apple.com/iphone/library/samplecode/AdvancedURLConnections/Introduction/Intro.html#//apple_ref/doc/uid/DTS40009558
you will store the information in the application keychain which is not accessible by any other application unless you share that keychain using your app id.