긍정적 사고, 음식의 절제, 규칙적인 운동

어제의 성공전략, 내일의 실패전략

소비자의 욕구는 엄청난 속도로 변화하기 때문에
작년의 성공전략은 오늘의 실패전략이 될 수도 있다.
이러한 환경 속에서 기업은 변화하는 기업과
사라지는 기업 두 가지로 나뉜다.
- 마케팅 대가 필립 코틀러, T-Plus 경영자료에서 재인용


실제 경험으로 살펴볼 때, 가장 변화가 어려운 사람들은
아이러니하게도 과거에 탁월한 실적을 낸 개인과 조직(팀)입니다.
드러커의 지적처럼 어제를 강화하는 것은 내일을 약화시키는 것입니다.

변화하지 않는 모든 생명체, 과거에 집착하는 모든 생명체는
반드시 죽게 되어있습니다.
우리 모두가 어제와 다른 새로운 미래 개척에
전력을 기울여야 할 이유가 여기에 있습니다.

동태전 만들고 남은 동태살이 있어서 이걸 어떻게 처리할가 하다가

동태간장조림을 만들어야겠다는 결론.

동태간장조림.  양념이 중요하다. 

만드는건, 무우 양파 바닥에 깔고 육수 넣고 동태 끓이다가 양념 넣으면 끝!

감정은 변덕스럽다.
조금 전까지 검은색이던 감정이
금세 푸른색이 된다. 심리학에는 '15'초의 법칙'이 있다.
하나의 감정이 치솟아 정점을 찍는 데 15초가 걸린다는
법칙이다. 화가 나면 화의 갈래로, 기쁨이 일면 기쁨의
갈래로 접어드는 데 3초가 걸리고, 그 감정의 정점은
15초면 도달한다. 그러고 나면 이내 다른 감정으로
변한다. '아, 이런! 고작해야 15초짜리 수명이라니.'
문제는 그다음이다.


- 김성수의 《글쓰기 명상》 중에서 -


* 15초.
짧은 시간입니다. 그러나
사람의 감정이 정점에 이르는 긴 시간입니다.
그 짧고도 긴 시간이 한 개인의 운명을 가를 수 있습니다.
만일 그 개인이 지도자의 반열에 이른 사람이라면
한 국가의 역사와 진운이 바뀔 수도 있습니다.
화가 치밀어 꼭짓점에 이르기 전에 잠깐
멈출 줄 알아야 합니다. 기쁨도 너무
넘치지 않도록 14초쯤에서
멈추는 것이 좋습니다.

반대를 용인하면 조직의 창의성이 높아진다

연구에 따르면 반대를 용납하는 집단은
그렇지 않은 집단보다 아이디어를 더 많이, 좋은 아이디어도 더 많이 도출한다.
이는 이러한 반대 견해가 완전히 틀린 경우도 마찬가지다.
그저 반대의 존재만으로 (틀린 반대일지라도) 창의성이 향상된다.
- 에릭 와이너, ‘천재의 지도’에서


좋은 아이디어만 좋은 것이 아닙니다.
정답만 찾으려고 하는 대신 반대 의견을 맘껏 낼 수 있도록
분위기를 만들어가는 것이 필요합니다.
반대가 많을수록 더 다양한 관점에서 살펴볼 수 있게 됩니다.
치열한 다툼과 토론이 더 나은 결과를 만들어냅니다.
최상의 결과를 위해선 반대와 갈등은 필수불가결한 요소입니다.

최근에 다시 쓸 일이 있어서 VSCode에서 python을 자동컴파일 할 수 있도록 셋팅했다. 

결국 한글을 얼마나 잘 가공할 수 있느냐가 문제인데. 

아나콘다를 이용해서 윈도우에서 VScode에서 개발 할 수 있게 셋팅하기. 

VScode 확장에서 파이썬, extension pack 설치하고. 

결국 여러 검색 내용을 참조하지만. 

* 파이썬 가상환경을 만들어야 한다.

* conda로 할꺼면 가상환경내에서 conda로 설치해서 반영될 수 있도록 한다. 

* vscode에서 해당 파이썬 파일을 실행할때, 컴파일이 제대로 안되면  작업하는 파일의 경로를 꼭 확인해봐라. 

* 파일 경로, 인스톨된 라이브러리 만 잘 확인하면 왠만해서는 구문오류만 생긴다. 

https://konlpy.org/ko/latest/

https://jwt.io/

https://brunch.co.kr/@jinyoungchoi95/1

JWT(Json Web Token)은 위와 같은 일련의 과정 속에서 나타난 하나의 인터넷 표준 인증 방식입니다. 말 그대로 인증에 필요한 정보들을 Token에 담아 암호화시켜 사용하는 토큰인 것이죠.

JWT는 리소스에 대한 액세스 권한을 부여할 수 있는 자격 증명입니다. 붙여넣는 위치에 주의하세요! 우리는 토큰을 기록하지 않으며 모든 유효성 검사 및 디버깅은 클라이언트 측에서 수행됩니다.

JSON 웹 토큰이란 무엇입니까?

JWT(JSON Web Token)는 당사자 간에 정보를 JSON 개체로 안전하게 전송하기 위한 간결하고 자체 포함된 방법을 정의하는 개방형 표준( RFC 7519 )입니다. 이 정보는 디지털 서명되어 있으므로 확인하고 신뢰할 수 있습니다. JWT는 비밀( HMAC 알고리즘 사용)을 사용하거나 RSA 또는 ECDSA 를 사용하는 공개/개인 키 쌍을 사용하여 서명할 수 있습니다 .

JWT를 암호화하여 당사자 간의 비밀도 제공할 수 있지만 서명 된 토큰 에 중점을 둘 것입니다 . 서명된 토큰은 그 안에 포함된 클레임의 무결성 을 확인할 수 있는 반면 암호화된 토큰 은 이러한 클레임을 다른 당사자로부터 숨길 수 있습니다. 공개/개인 키 쌍을 사용하여 토큰에 서명할 때 서명은 개인 키를 보유하고 있는 당사자만 서명했음을 증명합니다.

JSON 웹 토큰은 언제 사용해야 합니까?

다음은 JSON 웹 토큰이 유용한 몇 가지 시나리오입니다.

• 권한 부여 : JWT를 사용하는 가장 일반적인 시나리오입니다. 사용자가 로그인하면 각 후속 요청에 JWT가 포함되어 사용자가 해당 토큰으로 허용되는 경로, 서비스 및 리소스에 액세스할 수 있습니다. 싱글 사인온은 오버헤드가 적고 여러 도메인에서 쉽게 사용할 수 있기 때문에 오늘날 JWT를 널리 사용하는 기능입니다.
• 정보 교환 : JSON 웹 토큰은 당사자 간에 정보를 안전하게 전송하는 좋은 방법입니다. 예를 들어 공개/개인 키 쌍을 사용하여 JWT에 서명할 수 있기 때문에 발신자가 누구인지 확인할 수 있습니다. 또한 헤더와 페이로드를 사용하여 서명을 계산하므로 콘텐츠가 변조되지 않았는지 확인할 수도 있습니다.

JSON 웹 토큰 구조는 무엇입니까?

간결한 형태의 JSON 웹 토큰은 점( .)으로 구분된 세 부분으로 구성되며 다음과 같습니다.

• 헤더
• 유효 탑재량
• 서명

따라서 JWT는 일반적으로 다음과 같습니다.

xxxxx.yyyyy.zzzzz

다른 부분을 분해해 봅시다.

헤더

헤더 는 일반적으로 JWT인 토큰 유형과 HMAC SHA256 또는 RSA와 같이 사용 중인 서명 알고리즘의 두 부분으로 구성됩니다.

예를 들어:

{
  "alg": "HS256",
  "typ": "JWT"
}

그런 다음 이 JSON은 JWT의 첫 번째 부분을 형성하도록 인코딩된 Base64Url 입니다.

유효 탑재량

토큰의 두 번째 부분은 클레임을 포함하는 페이로드입니다. 클레임은 엔터티(일반적으로 사용자) 및 추가 데이터에 대한 설명입니다. 클레임에는 등록 , 공개 및 비공개 클레임 의 세 가지 유형이 있습니다 .

• 등록된 클레임 : 필수는 아니지만 유용하고 상호 운용 가능한 클레임 집합을 제공하기 위해 권장되는 미리 정의된 클레임 집합입니다. 그 중 일부는 iss (발급자), exp (만료 시간), sub (제목), aud (대상) 및 기타 입니다.
• JWT가 압축을 의미하는 한 클레임 이름은 단 3자입니다.
• 공개 클레임 : JWT를 사용하는 사람들이 마음대로 정의할 수 있습니다. 그러나 충돌을 방지하려면 IANA JSON Web Token Registry 에서 정의하거나 충돌 방지 네임스페이스를 포함하는 URI로 정의해야 합니다.
• 비공개 클레임 : 사용에 동의하고 등록된 클레임 이나 공개 클레임 이 아닌 당사자 간에 정보를 공유하기 위해 생성된 맞춤 클레임입니다.

페이로드의 예는 다음과 같습니다.

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

그런 다음 페이로드는 Base64Url 로 인코딩되어 JSON 웹 토큰의 두 번째 부분을 형성합니다.

서명된 토큰의 경우 이 정보는 변조로부터 보호되지만 누구나 읽을 수 있습니다. 암호화되지 않은 경우 JWT의 페이로드 또는 헤더 요소에 비밀 정보를 넣지 마십시오.

서명

서명 부분을 생성하려면 인코딩된 헤더, 인코딩된 페이로드, 비밀, 헤더에 지정된 알고리즘을 가져와서 서명해야 합니다.

예를 들어 HMAC SHA256 알고리즘을 사용하려는 경우 서명은 다음과 같은 방식으로 생성됩니다.

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

서명은 메시지가 도중에 변경되지 않았는지 확인하는 데 사용되며 개인 키로 서명된 토큰의 경우 JWT의 보낸 사람이 누구인지 확인할 수도 있습니다.

모두 합치다

출력은 HTML 및 HTTP 환경에서 쉽게 전달할 수 있는 점으로 구분된 3개의 Base64-URL 문자열이며 SAML과 같은 XML 기반 표준과 비교할 때 더 간결합니다.

다음은 이전 헤더와 페이로드가 인코딩되어 있고 비밀로 서명된 JWT를 보여줍니다. 

JWT를 사용하여 이러한 개념을 실행하고 싶다면 jwt.io 디버거 를 사용하여 JWT 를 디코딩, 확인 및 생성할 수 있습니다.

JSON 웹 토큰은 어떻게 작동합니까?

인증에서 사용자가 자격 증명을 사용하여 성공적으로 로그인하면 JSON 웹 토큰이 반환됩니다. 토큰은 자격 증명이므로 보안 문제를 방지하기 위해 세심한 주의를 기울여야 합니다. 일반적으로 토큰을 필요 이상으로 오래 보관해서는 안 됩니다.

또한 보안이 취약하기 때문에 민감한 세션 데이터를 브라우저 저장소에 저장해서는 안 됩니다.

사용자가 보호된 경로 또는 리소스에 액세스하려고 할 때마다 사용자 에이전트는 일반적으로 Bearer 스키마 를 사용하여 Authorization 헤더 에서 JWT를 보내야 합니다. 헤더의 내용은 다음과 같아야 합니다.

Authorization: Bearer <token>

이는 특정 경우에 상태 비저장 권한 부여 메커니즘이 될 수 있습니다. 서버의 보호 경로는 Authorization헤더에 유효한 JWT가 있는지 확인하고 JWT가 있는 경우 사용자는 보호된 리소스에 액세스할 수 있습니다. JWT에 필요한 데이터가 포함되어 있으면 특정 작업에 대해 데이터베이스를 쿼리해야 할 필요성이 줄어들 수 있지만 항상 그런 것은 아닙니다.

토큰이 Authorization헤더로 전송되면 CORS(Cross-Origin Resource Sharing)는 쿠키를 사용하지 않으므로 문제가 되지 않습니다.

다음 다이어그램은 JWT를 얻고 API 또는 리소스에 액세스하는 데 사용하는 방법을 보여줍니다.

1. 애플리케이션 또는 클라이언트가 권한 부여 서버에 권한 부여를 요청합니다. 이것은 다른 권한 부여 흐름 중 하나를 통해 수행됩니다. 예를 들어, 일반적인 OpenID Connect 호환 웹 애플리케이션은 인증 코드 흐름/oauth/authorize 을 사용하여 엔드포인트를 통과합니다 .
2. 권한이 부여되면 권한 서버는 애플리케이션에 액세스 토큰을 반환합니다.
3. 애플리케이션은 액세스 토큰을 사용하여 보호된 리소스(예: API)에 액세스합니다.

서명된 토큰을 사용하면 토큰에 포함된 모든 정보가 변경할 수 없는 경우에도 사용자 또는 다른 당사자에게 노출됩니다. 즉, 토큰 안에 비밀 정보를 넣으면 안 됩니다.

JSON 웹 토큰을 사용해야 하는 이유는 무엇입니까?

SWT(Simple Web Tokens) 및 SAML(Security Assertion Markup Language Tokens )과 비교할 때 JSON 웹 토큰(JWT) 의 이점에 대해 이야기해 보겠습니다 .

JSON은 XML보다 덜 장황하기 때문에 인코딩될 때 크기도 작아져 JWT가 SAML보다 더 간결해집니다. 따라서 JWT는 HTML 및 HTTP 환경에서 전달하기에 좋은 선택입니다.

보안 측면에서 SWT는 HMAC 알고리즘을 사용하는 공유 비밀로만 대칭적으로 서명할 수 있습니다. 그러나 JWT 및 SAML 토큰은 서명을 위해 X.509 인증서 형식의 공개/개인 키 쌍을 사용할 수 있습니다. 모호한 보안 허점을 도입하지 않고 XML 디지털 서명으로 XML에 서명하는 것은 JSON 서명의 단순성과 비교할 때 매우 어렵습니다.

JSON 파서는 객체에 직접 매핑되기 때문에 대부분의 프로그래밍 언어에서 일반적입니다. 반대로 XML에는 자연스러운 문서 대 개체 매핑이 없습니다. 이렇게 하면 SAML 어설션보다 JWT로 작업하기가 더 쉽습니다.

사용에 관해서는 JWT가 인터넷 규모로 사용됩니다. 이는 여러 플랫폼, 특히 모바일에서 JSON 웹 토큰의 클라이언트 측 처리 용이성을 강조합니다.

 인코딩된 JWT와 인코딩된 SAML의 길이 비교

JSON 웹 토큰에 대해 자세히 읽고 이를 사용하여 자체 애플리케이션에서 인증을 시작하려면 Auth0에서 JSON 웹 토큰 랜딩 페이지 로 이동하십시오.