what does money not spent have to do with anything? it's money that didn't exist that was created. The point of the article wasn't to talk about what causes inflation, its to talk about how inflation is a tax, and the stimulus package turned a period of deflation into a period of inflation.
Ok... Getting a bit rude, so if you prefer we can end the discussion here, however first lets take a look at 2 links:
https://oauth.net/2/scope/
"Scope is a mechanism in OAuth 2.0 to limit an application's access to a user's account."
Literally the first sentence in the definition. If you prefer take a look at the definition on OAuth definition at https://auth0.com/docs/scopes/current/oidc-scopes.
Now which part of that exactly anything about authenticating the user or goes against what i've said? You'd be well advised to take your own advice.
> The author quote a case where an application have obtained a token on behalf of the user and that's valid too, but it's a less common (in my experience) scenario.
quite common in mine, especially when dealing with service oriented architecture. the public api is given a token, and it should use that token to authorize itself to use other services, or a cron job that performs actions on behalf of users.
> A user token tells you (the relying party) that the user has been authenticated to the satisfaction of the issuer (often Google, Microsoft, Facebook but it can be anyone inclusing your own authority). You can be sure the token has been issued by the issuer due to the signature. If you trust the issuer then you can trust the time-limited token.
But my point is (and the point of the article) is thats not what the token tells you. The token tells you (and the reason its called a bearer token) that whoever holds this token, can perform the list of actions defined within the scopes array. Which is completely different to saying we are 100% sure the user is who they say they are.
If the token told you the user is who they say they are, then why do you even need scopes? You could just assume the user is allowed to do anything they wanted to to their own resources.
>I think you're talking about delegation now.
> Services which are acting on the user's behalf (delegated) can pass the user's claims through too; can pass the whole JWT through. That services act on the user's behalf with delegated authority is a red herring, as far as I can see.
Whether its delegation or authorization, a JWT access token is the result. Keep in mind this isn't about the mechanism to how the IAM decides whether or not to issue a JWT token and to whom, but just what that JWT token means to the endpoint that will consume the token and decide what to do based on it.
> Services which are acting on the user's behalf (delegated) can pass the user's claims through too; can pass the whole JWT through
Services acting on a users behalf should not be resending the same JWT token, if they do you've set it up incorrectly. Each service has its own unique identifier, as part of the audience claim. A service that gets a JWT token with a different identifier should reject it, even if the JWT token is valid.
Well yes, but sometimes its not the user that authorizes the JWT token holder to perform the action to begin with, which is why there is the distinction between authenticating the user and authorizing a service to perform an action.
JWT tokens don't tell you what the user is allow to do, they tell you what the service/client is allowed to do on behalf of the user. There still needs to be a seperate check to see if the user themselves are even allowed to perform a particular action to begin with, to have even allowed something else to do it on their behalf, and thats what solves some of the stateness issue, in that, if you have for example an admin, who gets fired, even if they still have a valid JWT token that says the client is allowed to perform certain actions on their behalf, there is still a check to see if the user can perform those actions, so as soon as they are fired or demoted, the backend will instantly stop performing actions on their behalf regardless of what the JWT token says they can do.
Well the point is, Authenticating the user happens before the JWT token is issued, and authorizing an action happens after the JWT token is viewed. Authorizing a user on the backend to perform an action is an entirely different thing.
For example, a user signs in and gets a JWT token that has the permission Delete.Everything which in this example is the permission required to delete all a users resources, the client takes this and passes it to the backed. On the backend however, the user might not even be allowed to delete everything. Maybe they're under investigation, or maybe this particular service just doesn't allow it. But its not the role of the JWT to tell you whether or not this particular user is allowed to perform that action, all the JWT token tells you is that this user has allowed the bearer of the JWT token to perform that action on their behalf. But, doesn't mean the user is allowed to perform that action to begin with, so the user has given the client permission to perform an action they themselves aren't allowed to perform.
Well no, JWT tokens are there to validate a call can be made. e.g., that whoever has made the HTTP call to your API server has been allowed to do so by the user. JWT tokens aren't there to tell you what the user themselves are allowed to do. What the user is allowed to do is an entirely different thing and you shouldn't rely on bearer tokens to tell you that.
Depends on where the permissions logic is stored, but to add information such as the example of can user a access the data of company x, then the IAM provider has to make a call back to the service where this information is stored. Its unlikely you'd want to store logic like that within the IAM provider, nor is it necessarily possible.
But if you are relying on the IAM provider for user permissions, then you still have the bottleneck of a centralised permission service, its just now your IAM provider.
The only scenario i can think of where its more efficent, is in role based authentication.
Ah thanks.
I disagree though, with JWT tokens and especially assuming you’re using the redirect flow, for the server especially, the server doesn’t need to know if the user was even authenticated as it could be another service calling it, it only needs to know that whoever is calling it is allowed to act on behalf of the user and perform certain actions. An example of this would be if you connect your email to a CRM system, the crm system at that point might have been authorised by the user to send emails on their behalf, or might have been authorised by an admin to send users on everyone’s behalf. In the case where an admin has given permission then the CRM system can send emails on everyone’s behalf even if the user themselves were never authenticated.
I believe it is the role of the IAM provider to authenticate the user, JWT tokens authorise callers to perform actions.
Not exactly newsletters, but there are 2 interesting podcasts from The Indie Hackers Podcast, one with John O'Nolan and one with Louis Nicholls and it seems like they suggest the best ways of getting people interested in your paid content is just by answering a lot of questions for free on forums like Quora, Reddit, etc. Worth listening to i think anyway, the John O'Nolan one had a couple of good examples of paid content websites that have done well.
I mean, they talk about Walmart like it's the underdog, but its revenue is twice as large as Amazon's (despite its market cap being much lower). While Walmart is much better at sales via physical stores and Amazon is better at online sales, and while Walmart is investing in heavily in it's online platforms, Amazon is investing heavily in in physical stores.
So i don't think it's Walmart vs Amazon, it's Walmart and Amazon versuses everyone else. They're both building themselves up to be equal competitors in most ways, leaving everyone else behind.
No, Swift isn't like other langugaes which start from nothing.
Most languages come out quietly and build a userbase slowly but steadily, which results in more organic growth, so they will have a steadier curve. Existing developers however have no real pressure to move to the new language, and can do so at a comfortable pace IF they decide it is even worth learning.
Swift however was released to a huge population of existing iOS and Mac developers, in releasing Swift Apple basically set a timer on the end of life of Object C and it meant that all developers at some point or another HAVE to learn swift to continue having a healthy career as iOS/Mac developers or be relegated to maintaining legacy code (which usually doesnt last long for client applications). So they release it, instant exposure to all existing Objective C programmers, instant interest from nearly everyone in their target audience (existing developers), and they're all in a rush to begin learning about it as staying relevant depends on it. However once a large subset of existing developers have already learnt about it, interest dies down again and it evens out at a rate you would expect from any other language based on interest from NEW developers.
You shouldn't attempt to always be "switched on" as that is usually counter productive. Just measure what your current production level is, write it down, and make an effort to stay consistent or improve. That way when you set your goals for the day, you know what you can comfortably achieve, and when you acheive it, you know to stop or risk it affecting your next day negatively.
Honestly, think they stand a pretty good chance in making it successful, especially considering how good their domestic home appliance capabilities has become. Different things, but atleast the embedded systems/electrical engineering talent is there.
I think the issue is the definition of a microservice isn't really set, while those are good candidates for microservices, you can even design them for core functionalities, such as for example in some challenger banks, i've seen the architecture of one or two who would have a service for different functionalities,such as one for card transactions, one for dealing with the account balances, etc.
But in my experience atleast, one of the biggest issues with microservices is the speed impact. Even a difference of 100ms on a consumer facing application can be an issue. 200ms is a noticable delay, and if something is 1 second slower users will actually get pretty frustrated.
As for speed, the difference in speed can be massive, and JSON serialization/deserialization (the way it is commonly implemented atleast) is very compute heavy especially if it relies on reflection. So the speed difference can sometimes be 5-10x and in microservices is a bigger concern then network latency. When you're dealing with larger dataset this becomes even more obvious.
Using gRPC for example, instead of JSON, the difference can be a couple of hundred milliseconds, which changes the conversation entirely on whether or not splitting it into a microservice is worth while and if the end user will notice the impact.
Yeah exactly. They run after these vanity projects which i find are usually vanity driven or built on the desire but don't appear to want to put the work in to have a proper tech strategy or invest in it.
I think a lot of the time is that in these larger organizations it's less risky to simply do nothing at all then to try to innovate, as if you innovate and change how things were traditional done and then fail, everyone will blame you and it can be bad for your career, while if you sit back and do nothing then you can make excuses for why it wasn't your fault or that the organization itself was simply no longer relevant.